[WP 34S] Enhanced Y register display: fractions, bugfixes etc.

[Bit]

(02-21-2014 07:43 AM)Marcus von Cube Wrote:  I vote for code optimization over clock speed increase. I have no idea how bad battery life would be affected by increasing the clock frequency. It's still worthwhile to think about the latter if the device gets to sluggy despite all code improvements.

That's what I'd vote for, too.

(02-21-2014 07:43 AM)Marcus von Cube Wrote:  Ad 1: You'll need to test if all temporary displays and PSE still work as expected. The whole display update stuff is quite a mess, in parts introduced by me.

My guess is that most, if not all, temporary displays already work fine. That said, lots of more testing would be needed before we can be reasonably sure, and I haven't specifically tested PSE.

(02-21-2014 07:43 AM)Marcus von Cube Wrote:  Ad 2: Don't forget to update the post processing code which is used during the build to replace 32 bit code addresses by 16 bit tokens. All function tables exist in two variants: The condensed version which goes to flash and the source version which is read by the post processor to update the condensed tables.

If I had already done what Pauli suggested (merging function tables), this would definitely be necessary, but I haven't touched the function tables yet. Do you think a change in the post processing code is needed anyway?

(02-21-2014 07:43 AM)Marcus von Cube Wrote:  Do you think your Y display code can be modified so that it is user selectable instead of a compile time option? We'll need to find a bit to store this. We could use flag Y or add another MODE option, maybe sacrificing some other arcane setting.

I specifically designed the new code so that it takes little effort to make features configurable at run time. Currently there's a compile time option for controlling Y register display using flag J. I added it so as to remain funcionally compatible with the original code but I don't think flag J is a good choice. It'd be a trivial change to use another flag or the unused bit in _ustate, for example.

The cost would be that the size of the machine code increases by approximately 170 bytes if Y register display is run time configurable because extra condition tests and both code paths (with and without Y register display) need to be included.

If Y register display is run time configurable (personally I think statically enabling it would be fine), then it should be easily discoverable in my opinion, e.g. in the mode menu.