If prod({19,12}>abs(L₁-{46,43




EDIT: Or was the point not to produce optimized code? If so, nevermind me.

What you're experiencing is no bug, that's just what happens when you try to emulate a device with a 4MHz processor and decent 2D graphics hardware on a device with only a marginally faster processor, (virtually) no graphics hardware, and a smaller screen that requires downscaling to make (most of) the original image fit. In contrast to that, a gameboy emulator running on your computer has a processor that is thousands of times faster, powerful graphics hardware, and no downscaling necessary.

Is it possible to store a value to an arbitrary real number variable? I tried expr("1"+Str0+"A") as a test (where Str0 contains a store arrow), but it throws an error. I suspect it may not be possible, but if you can think of any hackish way to do it, that would be great. I don't want to have to resort to a 27-branch conditional.

RAM usage while compiling isn't a huge issue, since I'm sure with some changes to Axe, applications could be written straight to flash. The issue is how the app will actually run in the calculator's memory layout, which is split into four 16KB banks as follows:

• Bank 0, 0000-3FFF: ROM 0 (OS core)
• Bank 1, 4000-7FFF: swappable ROM (applications run here)
• Bank 2, 8000-BFFF: RAM 1 (all of static RAM, some user RAM)
• Bank 3, C000-FFFF: RAM 0 (some user RAM, VAT, stack, and other things)

For all intents and purposes, bank 1 is the only memory bank applications can occupy, which gives the 16KB limit. Multi-page apps allow you to have more than one 16KB page, but the issue is then that only a part of the application can be mapped into memory at one time. You then have to have special handling for calls, jumps, or memory reads that gap pages of your application. Assembly developers who make multi-page apps can intelligently decide where to put routines and data such that the amount of page swapping needed is minimal, and they can create custom routines to operate on off-page data. However, performing this analysis on arbitrary Axe code and knowing when page swaps are necessary is a much tougher challenge.

But I assure you that methods of tackling this tough challenge are on the back burner, so it might come to fruition some day.

squidgetx never fails to make awesome-looking stuff. But I'd certainly like to see how fast you could get that by trying to turbocharge it to maximum Axe capabilities.

This is the effect of neither the OS nor Axe properly handling lists and matrices when creating arbitrary variables. Lists and matrices don't have the normal 2-byte size header that programs and appvars do; lists have a 2-byte header with the number of 9-byte elements, and matrices have two 1-byte entries for number of elements in each dimension. However, the arbitrary variable creation B_CALL doesn't handle lists or matrices in any special way, so the OS only allocates as many bytes as the size argument you pass to it and writes that value to the variable header. So GetCalc("L₁",10) would cause the OS to allocate 10 bytes in RAM (+2 bytes for the header) and write $000A to the header. However, after it's created, if the OS subsequently looks at it, it will think it's a list with 10 elements, and thus much larger. Deleting this will result in deleting more memory than was allocated, causing your crash.

A special case for lists and matrices could be added to Axe, but I think that would add too much size for such rarely-created variable types. You can correct it manually yourself fairly easily though, like this:

!If GetCalc("L₂",N*9)→L
.Error
End
N→{L-2}ʳ

Or, optimized:
EDIT: calc84maniac says this may be unsafe, so for the costs of 2 bytes, perhaps just skip it.

!If N→{GetCalc("L₂",N*9)→L-2}ʳ+1
.Error
End


Code: [Select]

Lbl DIFF1
0→A→B→C→S→T→R→U→D→I→θ→G→{L1}→{L2}

storing something into a Ram location pointed to and will return the address of that location, not the value.

You're basically doing that - which is not what you want:

Code: [Select]

0→{L1}
L1→{L2}


Only applies if the pointer is not a constant! L₂ is a constant, so that part of his code is fine.

then, the elses here make absolutely no sense to me:

Code: [Select]

:If K=15
:Goto DIE:End
:If K=33
:0→L:Else:End
:If K=34
:1→L:Else:End
:If K=26
:2→L:Else:End
:If K=16
:3→L:Else:End
You could also use a LUT and the inData( Command.

Also, I think you want 18, not 16, for the "3" key.

Use + instead of "or" and * instead of "and" in when doing conditionals, those are bitwise operations.

Code: [Select]

If {L1+(θ*4)}=(X+1) or ({L1+(θ*4)}=(X-2)) or ({L1+(θ*4)}=X) or ({L1+(θ*4)}=(X-1)) or ({L1+(θ*4)}=(X+2))

In a long chain of or's like this, substituting them for +'s is a good optimization. But if you have any and's, I would stick with the bitwise logic operators and not substitute them for arithmetic operators. In any case I wouldn't substitute and with *, because multiplication is not a native operation on the z80 and takes much longer than bitwise and.

Quote from: Derf321 on September 03, 2012, 10:12:47 pm

What is a LUT and what does inData do?

LUT stands for Look-up-table. It is basically just a constant array with values. You can get each value by accessing the data with an index. That is usually a lot faster than having a calculation for it.

Example:

Code: [Select]

{0,1,4,9,16,25,36,49,64,81,100,121,144,169,196,225}→GBD1  ; a LUT with the squares of 0-15
...
instead of a calculation like
A²→B
you can use the LUT:
{A+GBD1}→B


Remember, the syntax to create a list of data in Axe is different from that in TI-BASIC:
Data(0,1,4,9,16,25,36,49,64,81,100,121,144,169,196,225)→GBD1

(Data( is really the ∆List( token)

You can use an LUT also the other way round. Axe provides the function inData() for that.

Quote from: Axe Command List

inData(BYTE,PTR)     Searches for BYTE in the zero-terminated data. If found, it returns the position it was found in (starting at 1). If not found, 0 is returned.

Zero-terminated means, that the last value of the LUT has to be 0 respectively the first 0 in the LUT is considered as the end.

Say, at the beginning of the code we have a LUT with our keys, ending with 0:

Code: [Select]

{33,34,26,16,0}→GBD1at the point where we need the data, we use inData().

Code: [Select]

If inData(K,GBD1)→F   ; if the key is one of the weapon selectors
F-1→L         ; take this value (1-4) and subtract 1 (then we have 0-3) and store it in L.
End
optimized to save a variable:

Code: [Select]

If inData(K,GBD1)  
-1→L   ; that is the subtraction minus sign, same as above. It subtracts from the last evaluated expression, which is "inData"
End


There's currently a bit of an issue with this code that may be solved in the next version of Axe. The issue is that, if K happens to be 0, inData(K,GDB1) will return the position of the terminating zero in GDB1 which is 5, instead of the expected value of 0 for no match. Until then, the best fix for this is to add one to all the key values in GDB1 (and remember that the "3" key is 18, not 16) and do inData(K+1,GDB1).

Also, list syntax!


But otherwise good job helping out MGOS, it's always nice to see people willing to help others transition to Axe.

A few notes about the locking program:

• Since it looks like you're just using appvTEMP for 4 bytes of temporary storage, you don't really need an appvar for it at all. You could read the password the user enters into any 4-byte section of static RAM, like L₁. To clarify a little bit, "static RAM" is RAM that is always allocated for certain things. Many static RAM location do no hold essential data during assembly program execution, so you can use them as temporary storage without having to request dynamically-allocated storage in user memory.
• Get rid of the two DelVar commands that you have at the end of the program. In Axe, the A-theta variables are assigned to a section of static RAM, so there's no need to delete them when your program ends because they aren't real variables that consume user memory. Also, DelVar expects the argument passed to it to be a string containing the name of the variable to be deleted, not an actual variable token. I wouldn't be surprised if this is what's causing the RAM clear.