It's a B_CALL to the boot code, so it should exist on every OS with boot code. In other words, every OS.

Those two blocks of code are different in a few ways:

• Whereas the first block of code stores the value 20-{E} to the byte pointed to by E, the second block of code stores this value directly to E. In this case, the first block of code probably does what you want.
• Whereas the second block of code compares the value of the byte pointed to by E to 10, the first block of code compares the value of E to 10. In this case, the second block of code probably does what you want.

Put the two together and you get this, which I believe should do what you want:
If {20-{E}→{E}}>10


This looks pretty cool. I haven't actually played PvZ myself, but supposedly a lot of people like it. Anyways, I'd love to help you with your problem, but the zip file you attached is empty.

They're different. Although the memory read only reads a 1-byte value, all Axe math is done with 2-byte numbers. So the first statement would evaluate to 255+1=256, which is nonzero and will not activate the !If condition.

Ah okay, that's great. I was going to suggest that originally, but figured the variable problem would make it too hard to implement.

I think Quigibo and I both agree that π would be a good token for the following feature, as it is quickly accessible and will probably be used far more often than binary numbers.

Second, could static pointers and constants not require the first token to be a GDB, Pic, or Str token? I see this as being most easily implemented by allowing define references to be prefixed with an easily accessible token like π, which would dictate that what follows is a define and not a variable. Some sample code of old and new static pointers coexisting:

Code: [Select]

"appvTILEMAP"→πAPV
"Not enough RAM!"→Str0E

!If GetCalc(πAPV,4096)→M
  Disp Str0E
  getKeyʳ
  Return
End


I think pi is going to be used for a feature I suggested, hopefully coming up in 1.0. Anyway pi doesn't seem like a very intuitive binary indicator, at least to me.

Inverse/white drawing for commands that currently cannot might be nice. However, I'm not sure how being able to provide a whole list of buffers to apply a command to would be useful. I can't see why you'd want to apply the command to any more than two buffers in the first place, and if so, you can easily do something like:

Pt-On(expression→r₁,expression→r₂,expression→r₃)
Pt-On(r₁,r₂,r₃)ʳ

Because of how arguments are loaded and read, it wouldn't even be possible to optimize this much by combining the two into "one" command. Also, this is sort of a weird request in general, because the syntax style of applying a command to a list of buffers is strange.