Hmm, I think I know the problems:

I have an issue with the keypresses and it apparently isn't reading the last key group.
I have an issue with the sprite drawing (I forgot to include clipping), so this probably caused any crashes.
The reason for why it seems like you aren't moving the sprite is because with a sprite delay of 0, it is actually being interpreted as 256. Essentially, when you press a key like the left key in your code, it is incrementing the X coordinate a bunch of times before the update
Without updating the sprite so often, code is executed pretty quickly. I think it averages about 10000 instructions per second. To set up the update timer, try:
ldirc(keyMask,4)
  .db 3,1,1,1
The last '1' says to update the next sprite at each instruction. Keep in mind that it cycles through each sprite one at a time, so Sprite0 gets updated every 8th instruction. With a delay of 256, there was time for 2048 instructions to execute and pressing down looped through 4 instructions in your code meaning Y could get incremented 512 times before updating the sprite.

To answer your question about making an easier way to make/edit programs, I should have probably mentioned that the code can be in a program or appvar. So if you can get some kind of assembler to compile the code to a program, you can do something like:
"[JADETEST":Asm(prgmJADE
And that will execute the program named JADETEST as a JADE program. Use '5' instead of '[' to execute an appvar.

Now I have a few propositions for changes to the current instruction set and port setup. After trying to code in this language, it is obviuos that it is rather clunky. So I want to use an idea that Runer suggested that might make the code smaller and faster. Right now, all of the instructions fit in 6 bits, but take up a byte. I could make all of the instruction have flag arguments. For example, you could do something like this:
Loop:
 cpc(key0,kDown)
 incz(sY0)
 cpc(key0,kUp)
 decz(sY0)
 cpc(key0,kLeft)
 incz(sX0)
 cpc(key0,kRight)
 decz(sX0)
 cpc(key1,kClear)
 ldcz(status,$80)
 jrb(Loop)
And that would be the code to move the coordinates of the sprite, which is 20 bytes compared to 50 bytes.

If I do this, then we will free up room for other types of instructions, too. For example, I think an instruction to set, reset, or toggle a flag is useful, as well as these commands:
  bits(const,addr)   ;will perform bitwise AND logic, but doesn't change (addr), only flags. Useful to see if one of the bits is set.
  inv(addr)          ;invert the bits
  rotl(addr)         ;rotate the bits left
  rotr(addr)         ;rotate the bits right
  shftl(addr)        ;shift the bits left
  shftr(addr)        ;shift the bits right
Here is my proposed outline for a new instruction set:
0 1 2 3 4 5 6 7 8 9 A B C D E F
0 lda() adda() adca() suba() sbca() xora() ora() anda() cpa() inc() rotl() shftl() pusha() pop() inv() ldira()
1 ldc() addc() adcc() subc() sbcc() xorc() orc() andc() cpc() dec() rotr() shftr() pushc() ex() bits() ldirc()
2 ret() setz() setc() togz() togc() jp1() jp2() jrf() jrb() call1() call2() callf() callb()
3
;Duplicate for execution on the c flag condition
4x,5x,6x,7x
;Duplicate for execution on the z flag condition
8x,9x,Ax,Bx
;???
Cx,Dx,Ex,Fx
There will then be room for 19 more instructions and possibly 64 more depending on what is done for the last set. As a quick note,these instructions are not included:
resz() resc()
These are equivalent to:
togzz() togcc()
For example, togzz() will only toggle the z flag if the z flag is set,so it only resets the z flag.

Proposed changes to the ports:
We need a better way to handle sprites. I have a few ideas:

• Draw a sprite only if sMask has the bit set and sUpdate has the bit reset.

Implications: When a sprite is drawn, sUpdate gets the corresponding bit set. This means that in order to update the sprite again, you need to reset the bit, essentially acknowledging that it has been drawn. This will allow the programmer to do proper cleanup on the LCD.

• Only update the LCD when bit 0 of the status port is set and Sprite7 has been drawn.

Implications: It is faster than updating the LCD every time a sprite is drawn and looks cleaner.

• When the LCD is updated, reset bit 0 of the status port.

Implications: All the sprites are drawn, so if you need to cleanup the buffer you can without the screen being updated.

• If these changes are made, the sTimer port can be removed and updates will be made as the ports are edited.

So if all of these changes are made, here is an example routine for moving a sprite:
#include "jade.inc"
.org $00
 jrf(start)
sprite:
.db %00111100
.db %01100110
.db %11000011
.db %11100111
.db $FF
.db $FF
.db $FF
.db $FF
start:
 ldirc(sprite0,5)
  .dw $100+sprite \ .db 0,0,2
 ldirc(keyMask,2)
  .db 3,1
Loop:
 orc(status,1)        ;set bit 0 of the status port
KeyLoop:
 cpc(key1,kClear)     ;Check if clear is pressed
 ldcz(status,$80)     ;Turn off Jade if the z flag is set by writing 80h to the status port
 cpc(key0,-1)         ;test if no keys are being pressed
 jrbz(KeyLoop)

 callf(SpriteWait)    ;In case not enough time has passed for the sprite to be drawn
 ldc(sUpdate,0)       ;Acknowledge the sprite drawing, allowing it to redraw the sprite (XORing twice results in no change)
 callf(SpriteWait)    ;We need to wait until the sprite is drawn before updating coordinates

 cpc(key0,kDown)
 incz(sY0)
 cpc(key0,kUp)
 decz(sY0)
 cpc(key0,kLeft)
 incz(sX0)
 cpc(key0,kRight)
 decz(sX0)
 ldc(sUpdate,0)       ;Acknowledge any sprites drawn, allowing the updated coordinates to be displayed
 jrb(Loop)

SpriteWait:
 cpa(sUpdate,sMask)   ;Check if all of the sprites are drawn
 retz()
 jrb(SpriteWait)


The two LDIRs are different in that one writes to a fixed address (1F.address.size.data) and the other uses a byte in RAM to figure out where to write the data.

And yes, I saw that I had an extra sMethod after I got offline, sorry .__. Your assembly translation is exactly correct, too!

The extra 3 after the LCD update thingy is something I forgot to document and that is the frequency for updating the sprites. 3 means it updates a sprite every three instructions, so this can really slow down code as you might imagine. As a note, this doesn't update all of the sprites at once, only one sprite at a time. It also updates the LCD when each sprite is drawn, so I should probably change that to update only after all the sprites are scanned.

Also, looking at your code, I like your naming syntax better for cpc, ldc, and ldirc. It makes more sense. I was actually worried that cpc() would not work, so I am glad that it does!

For the .inc file, that is lovely! Any ideas on a good port 34h? Also, saveSScreen is typically 86ECh, but it will work on 9872h, too.

Another thing that I realised is that savestates can be 128 bytes or 256 bytes, depending on the RAM being used.

Haha, that does sound like something he would do o.o It is like a complicated cellular automata. Actually, if I do figure out something that works, I might have to use this for a talk that I should be giving about the subject.

As an update, I am about to run the code through ORG to see how many mistakes I have made with it. If no mistakes have been made, then I have completed the assembly version emulating the instruction set and I will need to add in ports (which should be rather trivial).

I have begun the process of converting this to assembly now, so once it is complete, I will be able to have a copy of it on my computer (and so I can upload it here). I currently have all of the jumps and calls emulated and now I just have the math operations to finish and the others random things. For an example of the code that I wrote (in hex on my calc) that was emulated:
3020        ;jrf 32             ;jumps over the next 32 bytes
<32 bytes of masked sprite data>
1F2802      ;ldir keymask,2     ;copies two bytes to the RAM location at keyMask (these are ports keymask and sMask)
0303        ;.db 3,3
1F0008      ;ldir sLSB0,8       ;copies 8 bytes to the first two sets of sprite data ports
  02000303  ;.dw 2 \ .db 3,3    ;location of the sprite, coordinates
  12005535  ;.dw 18 \ .db 85,53 ;location of the second sprite, coordinates
3302        ;jrb $              ;jumps back two bytes to the start of this instruction. Causes an infinite loop.


I believe you will be given what type of program to create at the start of each section.

The simple answer is that it makes things so much easier to handle, you get a ton of variety in commands, and there are a lot less instructions. For example, you can use 32 bytes of RAM as variables and perform all math operations on any combination of variables using the same instructions.

Earlier I tried making the sprite grayscale, but it was pretty laggy when the screen scrolled. I know how to fix it, but it would be a bit of a pain to implement it