WP 34s: UP and Down key in program mode



Post: #15

Hi,

Using version 2.2 rev. 1782, I see that in program mode, when I keep the up key pressed, the calculator does a fast up-scroll through the steps of a program, but if do the same with the Down key, I just get a NULL and nothing else happens, so think is a little inconsistent. Is that the intended behaviour?

Thanks,

Miguel


Post: #16

the keys.c code to handle SST versus BST is different:

		case STATE_SST:
xeq_sst_bst(0);
OpCode = c;
OpCodeDisplayPending = 0;
break;
case STATE_BST:
xeq_sst_bst(-1);
break;

stepping works properly if those OpCode* lines are removed, or at least if OpCode is set to 0 on STATE_SST - not sure why those lines are there, though.

Edited: 2 Nov 2011, 12:29 p.m.


Post: #17

I changed this because I think it's a good idea to be able to NULL a command that is selected via SST. You see the command before it is executed and holding the key longer cancels it. This is, of course, incompatible with the autorepeat feature. The latter is therefore disabled for SST.

EDIT: In program mode, autorepeat should work. I've to check this.

Edited: 2 Nov 2011, 4:16 p.m.


Post: #18

Please look here.

Post: #19

Both directions should work symmetrically. What you observed is *not* the intended behaviour.


Post: #20

Yes, but only in program mode. I found the error. It's not in the keyboard handler but in xeq_bst_sst(). It will be fixed in an upcoming release.

In run mode, SST and BST are not symmetrical by design: A SST executes the instruction while BST only displays it. So autorepeat is fine for BST but for SST, NULLing makes more sense.

Edit: Fixed and committed but the present release is unstable so please be patient!

Edited: 2 Nov 2011, 4:58 p.m.


Post: #21

I used to be able to reflash the calc without losing data - a "Backup to flash" would leave me with a calc displaying "Restored" after flash. Now it's very common that after flashing I get "Erased" and I have to transfer my programs again.
Should I stop updating for a while until things "settle down" a little?

Cristian


Post: #22

v2.3 is pretty much a playground (or construction site) for new stuff to come with v3.0. Thus we closed v2.2.


Post: #23

Which revision number is the final 2.2? Is it considered stable?


Post: #24

I've put up a V2.2 earlier as a release package. This should work even with some minor problems left.

Post: #25

Quote:
Which revision number is the final 2.2? Is it considered stable?

I have SVN1797 as lastest (stable) 2.2 version.

After that Marcus introduced these new feature like LOCL, adresses with ".nnn" etc...

Franz


Post: #26

Thanks.

The version in the release package is "only" 1790. I'd hate to miss out on any improvements.

For what it is worth, through trial and error I determined that rev. 1805 is the last one identified as 2.2, with rev. 1806 and later being 2.3.


Post: #27

Quote:
For what it is worth, through trial and error I determined that rev. 1805 is the last one identified as 2.2, with rev. 1806 and later being 2.3.

Yes, but a few versions after 1797 (where some new features were implemented) didn't work correctly here - I couldn't even load flash files compiled with the assembler. So I don't think it's a good idea to use these SVNs.
Post: #28

1805 isn't very stable. Stick to an older release!

The current build is starting to get stable with all the new bells and whistles but with a slightly modified layout. The medium emulator skin is adapted (select option 4).


Forum Jump: