Posts: 3,283
Threads: 104
Joined: Jul 2005
We are about to update the release files on SF again. There are still some documentation changes pending. I've prepared a chapter about interactive programming that is available as a separate document in SVN in the doc folder: interactive.html.
Have fun with the new release!
Edited: 26 Aug 2011, 11:15 a.m.
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
SVN 1523: "disable the A argument to STOS/RCLS"
Why this?
Posts: 3,283
Threads: 104
Joined: Jul 2005
STOS A is a compile time selectable feature.
Calm down!
It's selected in the current build.
Edited: 26 Aug 2011, 11:35 a.m.
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
STOS A is a compile time selectable feature.
Calm down!
It's selected in the current build.
Calm down? I didn't upset myself, I just asked!
And of course I know that this 'downgrade' hasn't yet been compiled, but my question is still unanswered:
why remove it?
Edited: 26 Aug 2011, 11:44 a.m.
Posts: 653
Threads: 26
Joined: Aug 2010
Ah, let's see...
Quote: VIEW immediatly displays the register when encountered during execution of a program. When followed by PSE or STOP, the display persists. Only the next PSE or STOP will revert to the normal X display
This means that - unless VIEW is directly followed by STOP - there is no way to VIEW a certain value and then quit the program a few steps later with this value still in the display (while there may be something different in X). Which is something I always liked on the '41.
Quote:
There is no way to get the "Running Program" message back once it has been replaced by a programmed display
What about a simple CLD command like the one in the 41/42? There also is another benefit: If VIEW was changed so that it behaved in the proposed way, using CLD or not would leave it to the user whether to keep the display as it is or return to the standard X-display.
Dieter
Posts: 3,283
Threads: 104
Joined: Jul 2005
Quote:
Quote:
VIEW immediatly displays the register when encountered during execution of a program. When followed by PSE or STOP, the display persists. Only the next PSE or STOP will revert to the normal X display
This means that - unless VIEW is directly followed by STOP - there is no way to VIEW a certain value and then quit the program a few steps later with this value still in the display (while there may be something different in X). Which is something I always liked on the '41.
You got me! :) The word "directly" is to harsh, as you have correctly pointed out. VIEW followed some other commands followed by STOP will behave the way you want: The VIEW display is retained until a key is pressed. I meant that the sequence VIEW, PSE, STOP with or without some other statements in between will return to the X display when STOP is executed. The same is true for VIEW, PSE, PSE.
You will not need CLD to display X again, just do another PSE or VIEW X.
Posts: 2,247
Threads: 200
Joined: Jun 2005
Marcus,
You guys are the modern-day RPN calculator heroes. Just like we will celebrate in HHC2011 30 years since the PPC ROM came out, we hope to celebrate in decades to come the WP34S.
Namir
Posts: 653
Threads: 26
Joined: Aug 2010
To make things clear let's consider an example:
#Pi
VIEW X ; display 3,14159265359
9
9
9
9 ; sufficiently large number for the emulator,
9 ; omit a few nines on a real 20b or 30b
9
DSZ X
BACK 01 ; keep the 34s busy for a moment..
RTN ; and quit
This should display Pi, run a second or two while still displaying Pi, and finally stop. According to what you said: with Pi still in the display. But it doesn't. As the program finishes the display switches to zero, i.e. the value in X after the DSZ loop.
Try the same on a HP-41...
01 Pi
02 VIEW X
03 99
04 LBL 01
05 DSE X
06 GTO 01
07 RTN
...and it behaves as expected: it displays Pi, runs for a few seconds and then stops with Pi still in the display. Insert a CLD before the RTN and is quits with a zero, just as the 34s emulator does now.
Is it still an old version I use or didn't I get you right?
Dieter
Edited: 26 Aug 2011, 3:58 p.m.
Posts: 3,283
Threads: 104
Joined: Jul 2005
Nice catch!
It works the same as the 41C if you don't change the register contents between the VIEW and the STOP. The technical reason is that stopping the program causes a display refresh. In order to display the last VIEWed register again, the firmware stores the index of the register in memory. So when the program stops, a VIEW with the same register is carried out. Your program has changed the contents of this register before the stop. So it's not the same display but only the same register that is displayed.
We will most probably correct the documentation, not the behavior.
Posts: 4,587
Threads: 105
Joined: Jul 2005
Franz,
The development team had a long discussion about this. Result: we decided to allow saving the stack to a block of 4 or 8 general purpose registers and recalling it from such a block. First register of said block may be 00 ... 92 for SSIZE8 and 00 ... 96 for SSIZE4, respectively. ROMA LOCVTA CAVSA FINITA, or in German: "Des iss jetzt g'schwätzt."
Walter
Posts: 653
Threads: 26
Joined: Aug 2010
Quote:
We will most probably correct the documentation, not the behavior.
Three weeks ago we had this discussion regarding the good old '65 accepting digits > 7 in octal numbers. Technically, this should be qualified as a bug, but since it was documented in the manual... ;-)
Honestly, I did not expect this in a sophisticated project like the 34s. After your explanation I now understand why using VIEW gives the results it does, but I also think this should get fixed. In the code, not in the documentation.
Dieter
Posts: 3,283
Threads: 104
Joined: Jul 2005
Dieter, we can only fix it if it does not need more RAM because the non volatile is simply full. I have an idea but don't hold your breath.
Posts: 3,283
Threads: 104
Joined: Jul 2005
Hello Dieter,
the display bug should be fixed in SVN. Can you try your examples again?
Marcus
Posts: 653
Threads: 26
Joined: Aug 2010
The previous example now behaves as expected. Pi appears in the display, the program runs one or two seconds, and finally it stops with Pi still in the display. Works with aView as well. Fine.
There is just one thing: usually (well, on the HP-41, that is... ;-)) a VIEW or AVIEW message in the display can be cleared with the backspace key, so that X shows up again. Simply the same way an error message can be cleared. This is different here. Pressing the backspace key clears X, thus showing a plain zero. Like any other key in this situation, backspace does the same thing it usually does - it clears X. On the '41, pressing backspace while a message is displayed simply clears the message and shows X again. I think the 34s should also behave this way. And finally... a CLD command sounds useful now. 8-)
Dieter
Posts: 3,283
Threads: 104
Joined: Jul 2005
The BS behavior is one thing I don't like either. As usual, not easy to implement without breaking things.
CLD is not necessary, a PSE with any delay (even 0) does nicely. The first call to PSE should preserve the display but the next refresh (either by another PSE or by a program stop) will restore the standard view.
Posts: 349
Threads: 66
Joined: Apr 2007
It is funny....in the past, Richard Nelson has attempted to mark "calculator time" by naming "epochs" based on generations of calculator capabilities. This would approximately be (if I remember correctly) the HP65/67 as epoch 1, the HP41/71 as epoch 2 and the HP48/49/50 being epoch 3. But thinking about what has been happening over the past year or so (or perhaps longer), maybe the same time period could be partitioned a slightly different way - with epoch 1 being when people primarily wrote programs; epoch 2 being when they wrote "modules" (for the HP41 or 71) or "libraries" (for the RPL machines) and epoch 3 being when they wrote entirely new calculators (such as the 34S)!
Jake
Posts: 3,229
Threads: 42
Joined: Jul 2006
Pressing backspace has always cleared X even after a VIEW or AVIEW
(in alpha mode it back spaces).
As Marcus pointed out changing this without breaking other things will be more invasive than it appears. By the time the backspace key is detected and processed, the knowledge that a message or status is being displayed is gone. Status messages are set all over the place in the code.
I'm sure the behaviour could be changed, it isn't quite so simple as:
if (message) then
redraw
else
process backspace
An alternative is to press a prefix key and this is documented in the manual I believe.
Then again, we could just say the 41 got it wrong introducing an unnecessary mode :-D
- Pauli
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
An alternative is to press a prefix key and this is documented in the manual I believe.
Last sentence of the chapter "Messages", page 81 of 90 :-)
Walter
Posts: 3,283
Threads: 104
Joined: Jul 2005
It nevertheless bugs me. I've ideas how to detect a temporary display. It needs another bit of RAM which I will hopefully find. :-)
As some may have already noticed, the RPN annunciator now presents more information then before. It was, until now, only used to visually indicate that a key is being processed by going off for a short while after a key press. This has been extended slightly: RPN is only displayed when the LCD shows the actual value of X in the current mode. Temporary displays kill the annunciator. I cannot read out this annunciator directly (for technical reasons) but I can keep a shadow bit with the same information in non volatile memory somewhere. This may then be used to detect a temporary display and dismiss it on <-.
Edit: I've made an attempt to implement this. Would you please try it out?
Edited: 30 Aug 2011, 4:19 a.m.
Posts: 3,283
Threads: 104
Joined: Jul 2005
I've updated the ZIP file with the latest changes. There might still be things to correct so be patient if anything is broken. OTH, any reports about bugs are very welcome. (Not the bugs, the reports!)
Posts: 653
Threads: 26
Joined: Aug 2010
Quote:
It nevertheless bugs me.
Which is perfectly understandable. ;-)
Quote:
I've ideas how to detect a temporary display. It needs another bit of RAM which I will hopefully find. :-)
Hmmm... maybe it's roughly similar to the way the HP-41 did it: it had a dedicated message flag (50). ;-) This flag can even be tested in a user program to check whether a message is displayed or the goose is flying.
Quote:
I cannot read out this annunciator directly (for technical reasons) but I can keep a shadow bit with the same information in non volatile memory somewhere. This may then be used to detect a temporary display and dismiss it on <-.
Hmmm.... 8-)
Dieter
Posts: 653
Threads: 26
Joined: Aug 2010
I tried the new "backspace cancels message" feature. Works fine, even for cancelling the SHOW display.
I encountered a problem with the right mouse button as a shortcut for the h-key. I cleared the display and right-clicked on the decimal point. As expected, it changed from comma to point and vice versa. However, after a few times the "f" announciator (!) came on and the 34s started to behave strange. The comma/point switch showed no reaction, and suddenly "Rg X" showed up in the upper left corner of the display. I had not noticed this display before, it seems to list the contents of the registers (up/down keys show the stack, the lettered registers, then R00, R01, R02... etc.). I'm sure this is not a secret feature and documented somewhere. #-)
Once the emulator even showed the f-key with inverted colors, just as if the key was pressed permanently. There was not way to return to normal operation except a restart. No, right-click f did not help.
First I was not sure if some of this was exactly the way the new secondary mouse button features you described are supposed to work. But at least I can reproduce the error with the right-click on the key with the decimal point. After a few consecutive clicks the "f" announciator comes on, and things start getting a bit weird. ;-)
Dieter
Posts: 3,283
Threads: 104
Joined: Jul 2005
Quote:
First I was not sure if some of this was exactly the way the new secondary mouse button features you described are supposed to work.
I must admit that the whole button and keyboard business is a bit convoluted and my additions have added to it. I'm pretty sure I'll do a complete rewrite of the emulator some day. But not before HHC.
The register browser is started with f EXIT. So you must have somehow managed to get a permanent f down situation. The way, a pressed key is displayed by inversion of the button area isn't reliable enough. HP has done some tricks to make it work correctly but there have always been situation where a key was left in the inverted state.
Normally you can just exit the emulator (Alt+F4) and restart it without losing any work. I must admit that this is not optimal but the emulator has always been a testbed for the real firmware so I has only second priority. Nonetheless I'll have another look at it when I find the time.
BTW, to press a shift key, the PC keyboard can be used, too. The Keys F, G and H are mapped to the three shifts.
|