HP Forum Archive 20

[ Return to Index | Top of Index ]

wp 34s: DSE vs. DSZ (poll) Message #1 Posted by Walter B on 23 May 2011, 12:58 a.m. Hi all, Your opinion is requested once more: Bottom right on the wp 34s, on the '+' key, we've got DSE as f-shifted function (the traditional Decrement and Skip if Equal). Shall this be replaced by DSZ (Decrement and Skip if Zero as on the 16c)? ISG will stay there g-shifted anyway. Your votes, please :-) Walter

Re: wp 34s: DSE vs. DSZ (poll) Message #2 Posted by Paul Dale on 23 May 2011, 1:02 a.m., in response to message #1 by Walter B My vote is for DSZ. I use this a lot more than I use DSE. On the other hand, I use ISG more than ISZ. Weird huh? - Pauli

Re: wp 34s: DSE vs. DSZ (poll) Message #3 Posted by Walter B on 23 May 2011, 1:19 a.m., in response to message #1 by Walter B For symmetry reasons, I'd like DSE staying there. OTOH I acknowledge DSZ is easier to use due to its predefined decrement and final. Nevertheless, DSE is my (slight) favourite. Walter

Re: wp 34s: DSE vs. DSZ (poll) Message #4 Posted by Angel Martin on 23 May 2011, 1:50 a.m., in response to message #3 by Walter B Considering that DSZ was on the 67 and DSE made its way on the 41, I'd say DSE added flexibility to the mix - despite the slight inconvenience of having to define the lower limit. I don't suppose you can have both? If I had to chose, I'd go for DSE.

Re: wp 34s: DSE vs. DSZ (poll) Message #5 Posted by Paul Dale on 23 May 2011, 2:09 a.m., in response to message #4 by Angel Martin We have both commands and that isn't going to change. What we're trying to decide is which should be on the keyboard and readily accessible and which goes into the program catalogue and be slightly less accessible. - Pauli

Re: wp 34s: DSE vs. DSZ (poll) Message #6 Posted by Marcus von Cube, Germany on 23 May 2011, 2:09 a.m., in response to message #4 by Angel Martin They're both available, one on the keyboard, the other in a catalogue. The question is which one to put where for convenience. Not a big deal, really.

Re: wp 34s: DSE vs. DSZ (poll) Message #7 Posted by Andrés C. Rodríguez (Argentina) on 23 May 2011, 9:28 a.m., in response to message #4 by Angel Martin As far as I recall, if you use an integer no larger than 99999 as the starting value, DSE and DSZ will behave exactly the same. The final value would be 0, and the step, by default is 1 (or -1 in this case). So no special initialization will be needed for DSE in most cases. I would consider a change for ISG, since the initial value can have up to 5 digits and the final value may only have 3; which is not very convenient for an incrementing operation. But backwards compatibility and symmetry with DSE make it better to keep it the way it has been for the last 30 years. So my preference is to keep ISG and DSE in the traditional way. For the keyboard, my priority is ISG, then DSE and, last, DSZ.

Re: wp 34s: DSE vs. DSZ (poll) Message #8 Posted by M. Joury on 23 May 2011, 12:51 p.m., in response to message #7 by Andrés C. Rodríguez (Argentina) I was going to say: Given that DSE with no parameters is (from the programmers point of view and as noted earlier) the same as DSZ so my choice would be to go with DSE on the keyboard. However, on second thought, I suspect that internally DSZ is more efficient (?) and 9/10 time (maybe 99/100) when I use DSE I default it to the DSZ equivalent. I can always go looking for DSE when I really need it but as a keyboard default (and only if DSZ is more efficient) I would go with DSZ. BTW, I am going to assume that there is an ISZ function to match DSZ? I guess I could go look couldn't I but I don't currently have the emulator or manual handy. Cheers

Re: wp 34s: DSE vs. DSZ (poll) Message #9 Posted by Gerson W. Barbosa on 23 May 2011, 3:16 p.m., in response to message #8 by M. Joury Quote: BTW, I am going to assume that there is an ISZ function to match DSZ? I guess I could go look couldn't I but I don't currently have the emulator or manual handy. From the manual: "ISZ ... Increments r by one, skipping next program line if then |r| <1."

Re: wp 34s: DSE vs. DSZ (poll) Message #10 Posted by Walter B on 23 May 2011, 4:07 p.m., in response to message #9 by Gerson W. Barbosa Muito obrigado, Gerson :-)

Re: wp 34s: DSE vs. DSZ (poll) Message #11 Posted by Gerson W. Barbosa on 23 May 2011, 4:47 p.m., in response to message #10 by Walter B Gern geschehen! :-)

Re: wp 34s: DSE vs. DSZ (poll) Message #12 Posted by Paul Dale on 23 May 2011, 5:49 p.m., in response to message #8 by M. Joury Quote: However, on second thought, I suspect that internally DSZ is more efficient (?) and 9/10 time (maybe 99/100) when I use DSE I default it to the DSZ equivalent. Correct, DSZ is more efficient than DSE. Several multiplies, integer and fractional parts more efficient since the finishing value and increment don't need to be extract every time. DSZ also behaves differently when the value has a fractional component which can sometime be useful. Likewise, when the number is negative (which can be useful in integer mode). - Pauli Edited: 23 May 2011, 5:49 p.m.

Re: wp 34s: DSE vs. DSZ (poll) Message #13 Posted by Eddie W. Shore on 23 May 2011, 10:36 p.m., in response to message #1 by Walter B DSE. I like the flexibility of having an ending term.

Re: wp 34s: DSE vs. DSZ (poll) Message #14 Posted by M. Joury on 23 May 2011, 11:31 p.m., in response to message #13 by Eddie W. Shore Just making sure that we are not speaking apples and oranges. The choice is not between the functionality of DSZ vs. DSE (as noted elsewhere in this thread both are available as are ISZ and ISG -- thanks Gerson!). The question is which should appear on the keyboard. So, just to confirm, are you saying that you want DSE on the keyboard due to the availability of an ending term? Cheers MJ

Re: wp 34s: DSE vs. DSZ (poll) Message #15 Posted by Eddie W. Shore on 24 May 2011, 12:23 a.m., in response to message #14 by M. Joury Yes. I'll confirm my choice.

Re: wp 34s: DSE vs. DSZ (poll) Message #16 Posted by Walter B on 24 May 2011, 12:26 p.m., in response to message #15 by Eddie W. Shore So we have 4 votes for DSE and 2 for DSZ on the keyboard. As mentioned, DSE, DSZ, ISG, and ISZ are all featured in any case, two in P.FCN and two on the keyboard for direct access. Any more votes? I'll close the polling station 24h after this post or the last vote, whatever comes last :-) Walter

Re: wp 34s: DSE vs. DSZ (poll) Message #17 Posted by Dieter on 24 May 2011, 3:51 p.m., in response to message #16 by Walter B I would like to add a slightly different thought. In my humble opinion the whole keyboard layout should ensure fast and straightforward operation in most situations the user typically faces in his daily use. A programmable calculator that is first of all a calculator, and then a programmable device, should emphasize fast and easy manual calculations. Functions that are mostly used in programs, such as DSE, ISG, DSZ, ISZ are not required to be found on keys - for me it's perfectly fine if they are somewhere in a menu. I think their keyboard space can be used more efficiently for other everyday-functions that now are buried in the menues. For instance cube or cuberoot, or even better an x-th root function (does the 34s have one at all?). The only exceptions - programing functions that should be directly accessible from the keyboard - are some basic functions for short everyday programs. I would say this applies to LBL, RTN, GTO, XEQ and a few others. In other words: I would use the keyboard space used for DSE and ISG, as well as the two tests X=? and X<>? (which are the only ones that are not in the TEST menu) for something more useful, i.e. especially commonly used mathematical functions. Even a "Parts"-menu (like on other HP-calculators) for IP, FP, Trunc, Floor, Ceil etc., and maybe also RND and ABS might be fine if it makes room for other useful functions. How about that ?-) Dieter

Functions for PRG mode on the keyboard Message #18 Posted by Walter B on 24 May 2011, 5:50 p.m., in response to message #17 by Dieter Dieter, Quote: In my humble opinion the whole keyboard layout should ensure fast and straightforward operation in most situations the user typically faces in his daily use. A programmable calculator that is first of all a calculator, and then a programmable device, should emphasize fast and easy manual calculations. Functions that are mostly used in programs, such as DSE, ISG, DSZ, ISZ are not required to be found on keys - for me it's perfectly fine if they are somewhere in a menu. I think their keyboard space can be used more efficiently for other everyday-functions that now are buried in the menues. For instance cube or cuberoot, or even better an x-th root function (does the 34s have one at all?). Personally, I didn't use a cuberoot for years. And for the 17th root of x, I'm able to press 17 1/x y^x, so why waste one label for the x-th root of y? You see, mileages may vary. Quote: The only exceptions - programing functions that should be directly accessible from the keyboard - are some basic functions for short everyday programs. I would say this applies to LBL, RTN, GTO, XEQ and a few others. Agree on the first four, but which are the "few others"? After all, we don't have many of them on the keyboard ... 8-) Quote: I would use the keyboard space used for DSE and ISG, as well as the two tests X=? and X<>? (which are the only ones that are not in the TEST menu) ... since they are the only ones working with real numbers as well as with complex Quote: ... for something more useful, i.e. especially commonly used mathematical functions. Even a "Parts"-menu (like on other HP-calculators) for IP, FP, Trunc, Floor, Ceil etc., and maybe also RND and ABS might be fine if it makes room for other useful functions. Come on, which "everyday-functions" are you thinking of which aren't on the keyboard yet? Walter

Re: Functions for PRG mode on the keyboard Message #19 Posted by Dieter on 25 May 2011, 5:28 p.m., in response to message #18 by Walter B Hallo, Walter - Quote: Personally, I didn't use a cuberoot for years. And for the 17th root of x, I'm able to press 17 1/x y^x, so why waste one label for the x-th root of y? You see, mileages may vary. You bet they do. Personally, I haven't used complex numbers at all. And P<>R is essentially used here for nothing but the fast evaluation of sqrt(x^2 + y^2). ;-) I think the XROOT function, which is available on most "serious" HP calucators, is a useful addition. Typing x ENTER 17 1/x y^x does not compute the 17th root of x, it exaluates x^0,0588235294118. I like functions that provide a result as precise as possible, and XROOT is one of them, ensuring the result is exact to all 16 digits within 0,5 ULP. It also saves two keys since virtually all mathematical functions are shifted on the 34s (not your fault - the 34s has only seven rows of keys instead of the usual eight). The same goes for ln1+x and e^x-1. I often use these functions and I really miss them on the 35s. So I'm glad they are back on the 34s - deep down in a menu. By the way these are two candidates that can take the keyboard space of other functions that are mainly used in program mode. Quote: Come on, which "everyday-functions" are you thinking of which aren't on the keyboard yet? I already mentioned ln1+x and e^x-1. I also miss H.MS+ for standard calculations with angles and time. Another example is the VIEW function, I heard its position on the keyboard (h STO) is now replaced by something else. Also the date functions (dDAYS and DATE+) are handy for everyday use. For basic programming I like to have at least an input/output function like PROMPT or AVIEW. Personally, I also like the direct use of flags to set a mode or configuration for a program: for instance set a flag or clear it to tell the calculator you want fast results with mid-precision or you'll accept longer execution times for full precision results. That's why I like SF and CF on the keyboard (and flag announciators in the display). Dieter

Re: Functions for PRG mode on the keyboard Message #20 Posted by Ángel Martin on 26 May 2011, 8:07 a.m., in response to message #19 by Dieter Reading your post I can't help but think about the 41 keyboard design - which offers much of what you mention. I think it deserved much more praise than was given, an impeccable solution to balance the open-ended character of the system with the simplicity and elegance of a superb key layout - not intimidating at all, yet flexible and well thought-out... Oh well, such was life back then.

Re: Functions for PRG mode on the keyboard Message #21 Posted by Walter B on 26 May 2011, 10:15 a.m., in response to message #20 by Ángel Martin Ángel & Dieter, The HP41C got 39 keys, the WP34S 37. Besides the trivial equalities, where are the differences? The 41C features five keys without a shifted operation: ON, USER, PRGM, ALPHA, and the golden prefix. The 34S sports only three, i.e. f, g, and h. The 41C in ground state has Sigma+, 1/x, SQRT, SIN, COS, TAN, LN, LOG, and SST unshifted. For the 34S in ground state, Sigma+, 1/x, SQRT, y^x, SST, BST, and EXIT are primary. So the difference is SIN, COS, TAN, LN, LOG versus y^x, BST, and EXIT - 5 vs. 3 matching the different amount of keys. BST and EXIT are set for the 34S, y^x may be stored for later discussion. Of the shifted operations on the 41C, what does the 34S not show on its surface? Most prominent, the 41C features ASN and only one CATALOG. It shows five tests on its keyboard including FS?, and two more flag commands, and BEEP. That's it. OTOH, the 34S gives you keyboard access to hyperbolics, fraction modes, integer modes and operations, statistics, etc. plus a structured system of catalogs. We do not feature anything like ASN beyond the four hotkeys so far, however, and it's improbable we will ever do in this project. VIEW is not decided yet - it may well stay on the keyboard of the 34S. Yes, we don't show SF, CF, FS? - just tell me three adjacent places on the 34S where to put them and what to kick out there and we'll check. And yes, we didn't put the other functions on the surface Dieter mentioned. Again, feel free to suggest where you want them and what shall be dropped instead. But we are in a project stage now where I can hardly accept such plain wishes like "put this or that on the keyboard" - you have to tell me what you want off in exchange. XROOT is a function we may consider taking in X.FCN - if my fellow projecteers agree on it d:-) Walter Edited: 26 May 2011, 10:16 a.m.

Re: Functions for PRG mode on the keyboard Message #22 Posted by Angel Martin on 26 May 2011, 2:14 p.m., in response to message #21 by Walter B Hi Walter (Hallo Walter?), don't get me wrong I wasn't critizicing the WP34S keyboard layout at all - just offered some comments on the 41 design, that's all. For the record, what you guys are doing (have done) is nothing less than remarkable and wondrous - blowing new life on the otherwise lame (sorry, I'm biased) financial calculator and taking it where HP doesn't care/want/know how to go. Kudos to that. Tschuess, 'AM.

Re: Functions for PRG mode on the keyboard Message #23 Posted by Walter B on 26 May 2011, 4:36 p.m., in response to message #22 by Angel Martin Buenas tardes, Ángel, muchas grazias per sua eulogia :-) There's no need for apologies, I've just written a combined response to previous postings. BTW, I bow to many vintage calculators - some were revolutionary at their time, and I was lucky being of right age then to experience those years. Anyway, all this had been written many times already and is found in the archives. And you may have noticed I share your bias ;-) Walter

Re: Functions for PRG mode on the keyboard Message #24 Posted by M. Joury on 26 May 2011, 2:41 p.m., in response to message #21 by Walter B Hi Walter, I have been wondering about ASN. After all a lot of us have different requirements for our machines and the wonderful thing about the 41 was how easy it was to configure the keyboard layout to the users' requirements. So, is ASN terribly difficult to implement or is it an issue of available ROM space, or...? Has there been a discussion of this previously? If so sorry for the repetition. Cheers, MJ

ASN Message #25 Posted by Walter B on 26 May 2011, 4:52 p.m., in response to message #24 by M. Joury IIRC, Pauli and me had an internal discussion about key assigning quite early in this project but I don't find any reference right now. I guess we agreed on ASN being too difficult or complicated for our hobbyist's project. BTW, up to 2009 I used to place an ASSIGN or ASN in my (vapourware) layouts based on different calcs though not on the 20B. Walter

Re: ASN Message #26 Posted by Marcus von Cube, Germany on 27 May 2011, 3:11 a.m., in response to message #25 by Walter B For the time being, we have some constraints: Flash is running out, we need to improve on code size before we will add new functionality. Battery backed RAM is limited to 2KB and is full now. We plan to relocate the user program space almost completely to flash in a future version so we gain SRAM for other purposes such as more (type tagged) registers and/or key assignments. The present infrastructure on the device and the emulator do not provide the mechanics of detecting key down / key up. This is essential for the "NULL" operation of the 41C which makes perfect sense if you have an assignable keyboard.

Re: ASN Message #27 Posted by Tim Wessman on 27 May 2011, 10:16 a.m., in response to message #26 by Marcus von Cube, Germany There is a rather simple solution to this that I used in the 10bII+ for keys needing to be held down. Put a short timer on your key that waits a short time, and then checks if it is still down. If so, it will loop again for up to 2 seconds or whatever your threshold is (slowing down in the loop to save batts). Check inside your longer loop every 150 ms or something to see if still down. With proper tuning, it works great. TW Edited: 27 May 2011, 10:19 a.m.

Re: ASN Message #28 Posted by Marcus von Cube, Germany on 27 May 2011, 10:41 a.m., in response to message #27 by Tim Wessman Tim, I've put the keyboard scan into a timer interrupt, generated by the LCD controller(*). Checking if a key goes down or up is just a matter of some additional binary logic in this routine. I don't allow deep sleep while a key is down, so 'up' can be reliably detected. The only problem is that I haven't implemented the 'up' logic yet. If I add it, 'key up' will simply change the sign of the queued character. IIRC, the emulator kernel has provisions for this, too, which just need to be activated. (*) Why the LCD controller and not one of the timers? The former runs at the same speed always, while the latter depend on the current clock setting. I had a hard time implementing a reliable time base while switching CPU speed back and forth to conserve power. I was glad to find out that the LCD controller can do this for me much easier. The frequency is 51 Hz which can be tricked into a 100ms heart beat by some smart counting.

Re: Functions for PRG mode on the keyboard Message #29 Posted by Paul Dale on 26 May 2011, 5:32 p.m., in response to message #24 by M. Joury Yes, lots of discussion. Several discussions. The final decider was space. RAM is very limited (2kb in total, or so we thought at the time, Marcus found us a very small amount more). Keyboard assignments will require two bytes minimum per assignment. 37 keys with four shift planes is 296 bytes and this number is a minimum, there would be additional overheads as well. That isn't bothering to distinguish alpha mode, integer mode, complex as a prefix, -> as a prefix (all of we we do do). Being able to define keys on a non-expandable calculator with a relatively easy to navigate catalogue system simply wasn't worth the space. Bear the above in light of the "no dynamic memory allocation" rule I'd set myself early on. Then also consider the non-expandable nature unlike the 41c -- the function set is completely determined. I'm sure some people think that losing a minimum of 15% of available RAM for an assignable keyboard is worthwhile. We didn't. - Pauli

Re: Functions for PRG mode on the keyboard Message #30 Posted by M. Joury on 26 May 2011, 10:32 p.m., in response to message #29 by Paul Dale Fair enough. Sounds like it was carefully considered. I do have one question though: Why did you impose a "no dynamic memory allocation" rule on yourself? Allowing dynamic allocation would allow keyboard assignment ala the 41 where memory usage would not be fixed and could be determined by the needs of the user. Of course dynamic memory allocation does risk introducing bugs (is reliability the primary concern here) or is it something in the hardware, or something else entirely? Cheers, MJ

Re: Functions for PRG mode on the keyboard Message #31 Posted by Paul Dale on 26 May 2011, 11:52 p.m., in response to message #30 by M. Joury Reliability was my main concern. All other things were secondary at least in this project. A calculator has to just work always. You also need to be able to implicitly trust the results. - Pauli

Re: Functions for PRG mode on the keyboard Message #32 Posted by gene wright on 27 May 2011, 12:05 a.m., in response to message #31 by Paul Dale The ability to have programs in flash and to call them as subroutines as well as simply RUN them, greatly diminished my desire for dynamic memory allocation. Good job, guys.

Why we don't take every suggestion (sorry ;-) Message #33 Posted by Walter B on 27 May 2011, 12:03 a.m., in response to message #30 by M. Joury AFAIK, it's simply a matter of complexity. Most people are happy with a mid-range scientific which works (almost so far, we're working on it) while only very few would appreciate a high end study failing to become a product. Remember it's a hobbyist's project and we started from scratch in 2008. Personally, I didn't expect the size of the function set we've got now (the last manual of 2008 had 16 pages) - and during the last months, my main concern is the WP 34S may die in increasing complexity eventually. IMHO, OpenRPN (hi, old guys :-) died by that combined with the lack of project management. Pauli and me were contributing to OpenRPN, and we don't want to see the same result again. Hope that explains us being a bit reluctant sometimes ... :-/ Nevertheless, thanks for each and every suggestion :-) Walter

Re: Why we don't take every suggestion (sorry ;-) Message #34 Posted by Paul Dale on 27 May 2011, 12:37 a.m., in response to message #33 by Walter B Quote: Personally, I didn't expect the size of the function set we've got now. And Walter prevented me from adding a myriad more most of very limited use functions :-) - Pauli

Re: Why we don't take every suggestion (sorry ;-) Message #35 Posted by Paul Dale on 27 May 2011, 6:27 a.m., in response to message #33 by Walter B Quote: and during the last months, my main concern is the WP 34S may die in increasing complexity eventually. Which is partly the reason we've agreed to a feature freeze once the currently flash segment stuff is ironed out. The other reason is we're out of flash :-) If anyone here wants to rework the integer routines in ARM assembly, there is some decent savings to be had. Checking for carry and overflow is tedious and large using straight C but relatively easy in assembler. - Pauli

Re: Why we don't take every suggestion (sorry ;-) Message #36 Posted by Paul Dale on 27 May 2011, 8:07 a.m., in response to message #33 by Walter B To give people an idea of the amount of functionality we've squeezed in, there are: niladic commands 151 commands not taking an argument (ALL/Rv) monadic commands 116 commands that take one argument and return one result dyadic commands 37 commands taking two arguments and returning one result triadic commands 5 commands taking three arguments and returning a single result argument commands 110 commands that take an immediate argument (STO/RCL) multiword commands 10 commands that handle alpha labels special commands 43 others that didn't fit nicely That is a total of 472 distinct commands (plus a few extras mentioned below). Monadic and dyadic functions can often take complex and integer arguments -- these aren't counted separately here. In all there are 22164 op-codes (only counting one for the commands that address multiple character alpha labels so in reality there are many many many more 167 million or so). Complex argument commands are counted separately to real argument commands here. However, integer commands that can also take real arguments are not. This also doesn't include the ON + key combinations and some of the immediate action keys (SST, BST, EXIT and a few others). - Pauli

Re: Functions for PRG mode on the keyboard Message #37 Posted by Paul Dale on 27 May 2011, 2:31 a.m., in response to message #30 by M. Joury Dynamic key assignments will definitely take up more memory per key -- you've got to store the key (6 bits), the shift plane (3 - 5 bites) as well as the function code (16 bits, although this can likely be reduced a little bit with a fair amount of effort). - Pauli

Re: Functions for PRG mode on the keyboard Message #38 Posted by Tim Wessman on 27 May 2011, 10:17 a.m., in response to message #29 by Paul Dale Very small amount more (RAM)??? Interested to know about that. TW

Re: Functions for PRG mode on the keyboard Message #39 Posted by Marcus von Cube, Germany on 27 May 2011, 10:43 a.m., in response to message #38 by Tim Wessman Tim, it's just 50 bytes in a well known area of the controller. A hint: We don't need a blinking cursor. ;-)

Re: Functions for PRG mode on the keyboard Message #40 Posted by Paul Dale on 27 May 2011, 5:53 p.m., in response to message #39 by Marcus von Cube, Germany Come clean, the sources are available for Tim to inspect if he really wants. It is the LCD memory. It stays active while the screen is showing so things which need to be kept between keystrokes but not over power cycles can be cached there and main RAM turned off. A very nice find which netted us a extra program steps. Also a bit fiddle to use without destroying the display integrity. - Pauli Edited: 27 May 2011, 5:54 p.m.

Re: Functions for PRG mode on the keyboard Message #41 Posted by Paul Dale on 27 May 2011, 6:02 a.m., in response to message #21 by Walter B Quote: Yes, we don't show SF, CF, FS? - just tell me three adjacent places on the 34S where to put them and what to kick out there and we'll check. We have far less need of these three on the keyboard than other devices. Our flags are for programming only. All mode changes in the device are done via dedicated commands. Again this was a design decision early on. The result is the user doesn't need to remember any magic numbers to set the device up. Much as I like the 41 and 48 series calculators, their use of magically numbered flags for mode settings irks me -- more so for the 48 series that should have been able to use text (with later models providing a browser that did just this). Then when I'm writing and keying in programs for the 41, I find I don't use these three all that often -- FS?C and FC? seem to pop up a lot. The 34s extends the available flag operations considerably BTW. Anyway, I'll finish with a flag heavy program from the small 34s library. The sieve of Eratosthenes done without touching a single non-stack register -- everything is stored in the flags. 001: LBL B 002: 9 003: 9 004: SF->X 005: DSE X 006: BACK 02 007: CF 00 008: CF 01 009: 2 010: . 011: 0 012: 1 013: LBL 00 014: FC?->X 015: GTO 01 016: ENTER 017: IP 018: ENTER 019: STO+ Y 020: EEX 021: 5 022: / 023: + 024: . 025: 0 026: 9 027: 9 028: + 029: CF->X 030: ISG X 031: BACK 02 032: Rv 033: LBL 01 034: ISG X 035: GTO 00 036: RTN Use the STATUS key to view the results. I've also not tried to shrink this one so I'm sure the code can be improved. - Pauli

[ Return to Index | Top of Index ]

Go back to the main exhibit hall