Short explanation:

This isn't the fault of Axe, this is a hardware limitation. To make them simpler/cheaper to manufacture, many keypads/keyboards detect key presses using a grid layout, which can result in phantom key presses if certain keys are pressed together. As an interesting coincidence, this is very much related to my recent How cheap is your keyboard? topic.


Long explanation:

Spoiler For Technical explanation:

In the keypad hardware, the keys are laid out in a grid of horizontal and vertical "wires" in which a keypress connects the wires intersecting at the key's location:

                                                            Key Code

		FE	FD	FB	F7	EF	DF	BF	7F
	BF	GRAPH	TRACE	ZOOM	WINDOW	Y=	2nd	MODE	DEL
G	DF		STO	LN	LOG	x²	x?¹	MATH	ALPHA
r	EF	0	1	4	7	,	SIN	APPS	X,T,?,n
o	F7	.	2	5	8	)	COS	PRGM	STAT
u	FB	(-)	3	6	9	(	TAN	VARS
p	FD	ENTER	+	-	*	/	^	CLEAR
	FE	down	left	right	up

To detect a key, the user first tells the keypad driver that we're looking to retrieve the state of keys in a certain key group. A read from the keypad driver then returns an 8-bit number, with 1s representing locations where the key group wire is not connected to the key code wire (key not pressed), and 0s representing locations where they are connected (key is pressed). For instance, if you pressed TRACE, that would connect the BF key group with the FD key code wires, resulting in the FD key code bit reading as 0 when the BF group is polled:

                                                            Key Code

		1	0	1	1	1	1	1	1
	BF	GRAPH	TRACE	ZOOM	WINDOW	Y=	2nd	MODE	DEL
G			STO	LN	LOG	x²	x?¹	MATH	ALPHA
r		0	1	4	7	,	SIN	APPS	X,T,?,n
o		.	2	5	8	)	COS	PRGM	STAT
u		(-)	3	6	9	(	TAN	VARS
p		ENTER	+	-	*	/	^	CLEAR
		down	left	right	up

Now if you pressed a second key, let's say the down arrow key, this wouldn't affect reading the BF key group. But press the down arrow key and the left arrow key, and this happens:

                                                            Key Code

		0	0	1	1	1	1	1	1
	BF	GRAPH	TRACE	ZOOM	WINDOW	Y=	2nd	MODE	DEL
G			STO	LN	LOG	x²	x?¹	MATH	ALPHA
r		0	1	4	7	,	SIN	APPS	X,T,?,n
o		.	2	5	8	)	COS	PRGM	STAT
u		(-)	3	6	9	(	TAN	VARS
p		ENTER	+	-	*	/	^	CLEAR
		down	left	right	up

I have italicized the GRAPH key because it is now being detected as a phantom key press. Before pressing the left arrow key, pressing TRACE connects the BF key group to the FD key code. Pressing the down arrow key has no effect on polling the BF key group because it connects the FE key group to the FE key code, neither of which connect to the BF key group. But pressing the left arrow key acts as a link, connecting the key code of the TRACE key to the key group of the left arrow key, and resulting in the left arrow key's FE key code reading as pressed when polling the BF key group.

err....

I have a strange bug in axe 1.1.2

I compiled a programme and <crash>  RAM clear 

I compiled on ion a big programme ( 5752 octets)....

I have absolutely no idea why this line of code (even if it is in a condition and never ran in execution) mixes up things in the program (like graphics and data storage), but it still runs stable (no errors or crashes occur, it just doesn't do what it should).

Code: [Select]

{L1}+1->{L1}
if I change it to

Code: [Select]

1+{L1}->{L1}everything works perfectly (I know it is this line because I didn't change anything else and if I change it back the weird stuff happens again).

As said, the line is in a conditional and it doesn't have to run at all, the stuff happens always from the beginning of the execution, so it has to be axe's fault.

I can't post more because it is part of my contest entry and now I know what to change, so it's not a big deal for me, but it would be interesting to know why this stuff happens.