I've now finally finished my extended TVM-program. :-)

The first version of such a TVM-solver I've written in the good old HP-41 days, and since then ported it to many other different calculators (Sharp PC-1500, HP-48, TI-92+ ...).

I call it 'extended' because it has 2 additional parameters NP and NI (in English PF and CF for payment/compound frequency) which allows to set different periods for payments and compounding.

And furthermore it also handles 'perpetual payments' (i.e. where N=infinite), anticipative discount rates (NI<0) and continuous (or theoretical) compounding (NI=0).

It has 256 steps and is in *.wp34s format, so it can be compiled with the WP34S assembler - and a quite detailled description is included.

Let me know if there's any interest - I could either post it directly here in the forum or upload the file to my website.

Franz

Edited: 6 Aug 2011, 11:12 a.m.

Quote:

---

Let me know if there's any interest - I could either post it directly here in the forum or upload the file to my website.

---

Walter

Quote:

---

I'd suggest uploading your file to SourceForge where the WP 34S lives. If you agree, please send it to any member of the development team, and we'll put it in for you :-)

---

I've sent it now to Marcus ...

Of course feel free to add my 'Extended TVM-Solver' to your project site at Sourceforge if you want, but first make sure that it will meet your high quality standards for WP34s programs ... :-)

Franz

Edited: 8 Aug 2011, 8:28 a.m. after one or more responses were posted

I'm sure it will meet our standards. :-)

WP 34S features are still emerging and so it may be necessary to adapt existing software. Remember the recent discussion about labels beyond A to D. We are willing to keep the included programs in sync with the current feature set. If we find any discrepancy between used and available features we will happily adapt the code included in the package, including yours.

Quote:

---

Well Walter, I prefer a place where I have access to.

---

Ask and I'll give you subversion access.

Quote:

---

Of course feel free to add my 'Extended TVM-Solver' to your project site at Sourceforge if you want, but first make sure that it will meet your high quality standards for WP34s programs ... :-)

---

The program looks good. Only two very minor things to consider changing. Alpha registers are special so the saving and restoring the value into K at steps 13 and 15 isn't the best -- it will prevent using the statistical distributions and this financial package together. I'd suggest using L for this since that has been destroyed anyway rather than a grabbing another numeric register. Damn, CLSTK wipes out L so that won't work :-(

The other is the relevance of some of the error messages -- "bad mode" is used everywhere else to indicate that the device is in integer/real mode and the operation selected is only valid in real/integer mode. Like I said, fairly minor.

There are also a couple of SKIP statements that SKIP to a RTN. Why not just replace them with a RTN. e.g. Lines 78 and 84. Also, we're in the process of rethinking the extra labels again so there will likely be further changes in this area.

Anyway, a good library routine to have.

- Pauli

Edited: 6 Aug 2011, 8:08 p.m.

How about this to avoid using K:

	010 LBL 00	// return after input or calculation

	011 FS?C 00

	012 SKIP 04

	013 STO L

	014 0

	015 FILL

	016 RCL L

	017 STOP     	// wait for input or calculation

	018 BACK 01	// [R/S] -> clears ENTRY? flag

Costs one step and saves using one register.

This also avoids zeroing the I register which CLSTK does.

- Pauli

Edited: 6 Aug 2011, 8:20 p.m.

Quote:

---

Damn, CLSTK wipes out L so that won't work :-(

---

Quote:

---

The other is the relevance of some of the error messages -- "bad mode" is used everywhere else ...

---

Quote:

---

There are also a couple of SKIP statements that SKIP to a RTN. Why not just replace them with a RTN. e.g. Lines 78 and 84.

---

And for your other suggestion to replace this register K usage:

Well, clearing the stack at the end won't really be necessary at all - once again the fault of my tidiness. ;-) I just don't like to have any useless (intermediate) results on the stack. But maybe a simple FILL (the stack with the result) would be the best solution and even save a few bytes more!? :-)

Franz

Quote:

---

Costs one step and saves using one register.

---

010 LBL 00	// return after input or calculation

011 FS?C 00

012 SKIP 03

013 STO 09

014 CLSTK	// remove intermediate results

015 RCL 09

016 STOP	// wait for input or calculation

017 BACK 01	// [R/S] -> clears ENTRY? flag

Edited: 7 Aug 2011, 5:37 a.m.

Quote:

---

Well, clearing the stack at the end won't really be necessary at all - once again the fault of my tidiness. ;-) I just don't like to have any useless (intermediate) results on the stack. But maybe a simple FILL (the stack with the result) would be the best solution and even save a few bytes more!?

---

Walter

Quote:

---

Hmmmh, my understanding of tidiness at the end of a routine is having the result in X, and the other levels containing what was therein before calling said routine. Finishing a routine with CLSTK or FILL is a strategy of "burnt soil" IMHO ;-)

---

But this would require saving the stack before and restoring it after any calculations.

And since there's no such command in the WP34s (unless you're using still other registers Rnn), you would have to code it yourself.

Ok, not really a big problem (in SSIZE4 mode):

SaveStack:

cpx STO A

cpx x<>y

cpx STO C

cpx x<>y

RestoreStack:

cpx RCL C

cpx RCL A

BTW, the 2 routines above together with

SwapStack:

cpx x<>A

cpx x<>y

cpx x<>C

cpx x<>y

Franz

Edited: 7 Aug 2011, 7:17 a.m.

What about STOS and RCLS ??

We don't have a swap stack command but it doesn't seem all that useful to me.

- Pauli

Quote:

---

What about STOS and RCLS ??

---

Quote:

---

We don't have a swap stack command but it doesn't seem all that useful to me.

---

Franz

Edited: 7 Aug 2011, 8:53 a.m.

Quote:

---

What about STOS and RCLS ??

---

Edited: 7 Aug 2011, 9:21 a.m.

Well Franz, you've got 100 general purpose registers - use four of them at a nice address :-)

Quote:

---

Well Franz, you've got 100 general purpose registers - use four of them at a nice address :-)

---

A short note, Marcus:

I guess your changes of the shortcut labels are now permanent, so maybe it would be a good idea to also fix the TVM-solver code, because with the current build it doesn't work anymore as expected.

LBL G, H and I (in lines 047, 054 and 061) should be changed to LBL 21, 22 and 23 resp.

And there's a small typo in the description at th beginning:

After "Keyboard-Layout:" in 00N the 00 should be replaced by 2 spaces - I don't know where these 2 zeros are coming from!?

And maybe the 3 occurences of 'FIN' could be changed to 'TVM', but that's just a matter of taste and I let this be your decision. ;-)

Franz

Edited: 9 Aug 2011, 5:57 a.m.

BTW, I've found a nice trick for the problem to clear the stack but retain the X register (which was in discussion about my previously used method):

RCL- X

FILL

RCL L

PS: Once again I forgot something: since now there's this new error message for SLV, I've also changed this message in the program.

And furthermore I've also included the financial equations which are used in TVM in case someone is interested in these formulas.

The updated current version of TVM can be found here:

http://www.hpmuseum.org/guest/fhub/tvm.zip

Edited: 9 Aug 2011, 7:22 a.m.

An updated version of your code is now in the pre-compiled library. :-)

I have yet to check the latest ZIP package for the documentation changes.

Quote:

---

An updated version of your code is now in the pre-compiled library. :-)

I have yet to check the latest ZIP package for the documentation changes.

---

You only have to add your 'Intro' (=Vorspann) ... :-)

(maybe a 'sound intro' would be nice, too ;-))

Edited: 9 Aug 2011, 8:10 a.m.

Franz,

Quote:

---

- program 'TVM' should be loaded into and called from RAM

---

Any reason for this? The program should work fine in the library space.

Quote:

---

Any reason for this? The program should work fine in the library space.

---

The problem was the following:

I've opened the catalog with [h]CAT and clicked ENTER. I don't know exactly what internally happens when doing this, but it seems that the program-counter is then in the Flash-ROM and everything is working fine: I can list the program with [h]P/R and I can XEQ the shortcut labels, but: only those which end with a GTO 00 statement - if e.g. I do a XEQ 09 (which ends with RTN) to evaluate the TVM expression, the program-counter seems to be 'out of flash' after this RTN, and from that moment on none of the number-labels (00-09) is working anymore: trying to XEQ them just gives "No such label" (and also [h]P/R doesn't list the program anymore). I have to select the TVM program once more from the catalog to make it work again. Exactly the same happened after I made a GTO.. (I just wanted to restart it with R/S to reset all values) - after that the 34s also seems to 'forget' my TVM program.

So I believe that manually starting or excuting a program that ends with a RTN (or doing a GTO..) sets the program-counter back into the RAM, and so the program in the flash-ROM is no longer accessable (unless you chose it again).

I'm not sure if this is intended this way, but I just have too little internal knowledge about the WP34s - and I also haven't found any detailed infos about this so far.

Franz

Edited: 9 Aug 2011, 11:59 a.m.

I'll check it with Pauli. Thanks for the info. As long as you stick to the hot keys, everything is fine from the library space.

I just saw another small issue: when you go to program mode and view the listing of a flash program, then the first step starts with 002 (and also all other line numbers are one too high).

And for the other problem above - I think it's just the way RTN is implemented:

if a RTN at the end of a subroutine is executed, then it goes back to the address on the return-stack IF the subroutine was call from within a program. But if the user executes this subroutine manually, then there is no return address on the stack, and so the RTN command just jumps to the beginning of the programspace in RAM!

And this is the point: maybe it should not always return to the top of the programspace in RAM, but to the top of the 'currently selected' programspace, i.e. to the top of the Flash when this Flash was the last being used.

Edited: 9 Aug 2011, 1:23 p.m.

Regarding the listing issue I need to check it for myself.

You have fully understood the RTN problem. I've started a discussion with Pauli what the best way to treat this would be. Your proposal is one possible option.

Honestly, what do you want to do with more than 100 general purpose registers in such a calculator? Will be difficult to keep track of them already :-/

Quote:

---

Honestly, what do you want to do with more than 100 general purpose registers in such a calculator? Will be difficult to keep track of them already :-/

---

Quote:

---

as soon as you would like to deal with matrices, 100 registers are almost nothing.

---

1. I won't like to deal with them, since IMHO matrix math exceeds the limits of the UI of such a small scientific calculator - people are used to viewing a whole matrix at once nowadays, which is obviously impossible with the HW given,
   
2. if I were forced do deal with them, I won't employ any matrices larger than 4x4,
   
3. even with 5x5, two complete different systems of linear equations are easily stored simultaneously in the memory provided so far,
   
4. I didn't hear a widespread request for matrix math library routines yet.

Edited: 9 Aug 2011, 5:40 p.m.

Yes, I agree with you in (almost) all points - matrix math is definitely "one shoe number too large" (as we say in German ;-)) for the 34s.

And if you have to address them via sequential register numbers Rnn (instead of A[i,j]) the handling would in fact be a nightmare.

But I'm using it on the HP48GX and the TI92+ without problems, and especially on the latter it really makes fun - but of course not 100x100 monsters. :-)

Quote:

---

As long as you stick to the hot keys, everything is fine from the library space.

---

So it's indeed really a problem for every program called or used directly from the flash space. :-(