The Museum of HP Calculators

HP Forum Archive 16

[ Return to Index | Top of Index ]

WONDERFUL HP41 EMULATORS BY JEAN-FRANCOIS GARNIER AND HRASTPROGRAMMER (long)
Message #1 Posted by Antoine M. Couëtte on 30 Apr 2006, 3:48 p.m.

All this article deals with the way some of us have made the continued use of the HP41 possible, even some 30 years after this fabulous machine was first introduced by HEWLETT-PACKARD.

I am aware that many more people than the two ones celebrated here have been – extremely successfully – involved into the current revival of the HP41. My hat down to them also. Still I wish to draw your kind attention towards two very special men I have met in this field.

This might be a long story - maybe a repeat to some of you - but I feel higly indebted towards two very special people : Jean-Francois Garnier and HrastProgrammer. I wish to publicly command their extraordinary expertise and most importantly their outstanding help, as well as faithful and friendly support in the past 30 months.

****

It all started some 25 years ago when I was an aircraft carrier pilot flying the CORSAIR II single seat Attack Aircraft in the US Navy under an exchange program with the French Navy.

From previous course at the French Naval Academy, right after flying which has always been my favorite professionnal occupation - and I now fly the good old DC10-30 worldwide as a CARGO aircraft - I have always been extremely fascinated by Celestial Navigation, by other items or people too … but this is an other subject. :-) )

As soon as the HP41 was introduced, I realised that I was holding in my hands THE Calculator which could eventually allow me to fulfill a long time dream : automatic computation of Sun, Moon, Planets and brightest stars position WITH AN ACCURACY BETTER THAN 6 ARCSECONDS - the accuracy achieved through the use of the Nautical Almanach - AND (VIRTUALLY) NO TIME SPAN LIMITATION, all this in a “handheld” machine.

****

Starting in 1979 I began writing a number of Celestial Navigation routines, taking some inspiration of the then extraordinary HP41 NAVIGATION Module ( Congratulations again M. Kenneth Newcomer !!! ). To fulfill the objective of “unlimited” time span accuracy, thanks to information obtained in Washington from late Dr Leroy Dogget of the U.S.N.O. , I then met in Paris several times with Dr Jean Chapront and late Dr Pierre Bretagnon from the Bureau des Longitudes who were at that time just finishing their new ELP2000 and VSOP82 theories which they kept further developping and improving over the subsequent years.

For the Moon I am now using ELP2000-85 and for the Planets - all 8 Main Planets are included in my Software - I am using VSOP82+NGT which is extremely similar to VSOP87. VSOP82+NGT enables computations with 6 variables while VSOP 87 only yields the three usual X Y Z Variables. Computing with 6 (elliptic) variables immediately gives access to the planetary speeds while VSOP87 would need to be somewhat differentiated for this aim. For the stars I am using the FK5 Catalog, an area where the more recent FK6 Catalog would give little if none leading edge even on a long time span when it comes to the Celestial Navigation required accuracy. With the FK5 Catalog I achieve a computation accuracy better than 2/1,000 arcseconds on stars apparent coordinates when comparing my results with the examples then published in the Astronomical Almanach form 1984 onwards.

****

To solve the problem of the required Memory Capacity, I then identified W&W Gmbh in Germany and visited Wilfried Koetz and his micro-code software Engineer Heinz-Ado Arnolds. I first purchased one 32K RAMBOX from them. Since it was to “small” because I needed 64K, I then purchased one RAMBOX II and finally purchased their HP41CY Turbo. This superb machine allowed me to fully develop and test my Software and demonstrate that I exceeded my requirements in all respects. Happy me !!!

Unfortunately HP41 has become old and started decaying over the years. I was really worried that all my important work could not be saved in any way and would somewhat disappear.

****

This is when both Jean-François Garnier and HrastProgrammer came to play.

Jean-François had earlier developped his EMU41 running on PC. He first saved all my software ( some 64 K with over 30500 program lines ) from my HP41CY Turbo into his Computer. He then offered to me - for free - to upgrade his EMU41 into an HP41Y Turbo emulator. Very shortly after his kind offer Jean-François achieved this objective as a superb Piece of Art.

Thanks to you Jean-François, I have been able to save all my work and my software now runs some 600 times faster on EMU 41 than on a standard HP41 !

As an example, the (long ) INITialisation Program I need to save time for further computations takes some 85 minutes to run in a standard HP 41 and … less than 9 seconds on my laptop running EMU41 . CONGRATULATIONS AGAIN JEAN-FRANCOIS !!!

****

As I earlier mentionned, running Celestial Navigation Software on a HANDHELD computer has been my ultimate objective. At that time Jean-François Garnier introduced me to HrastProgrammer, and to make it short, Hrast did an extraordinary development work for me on HP48GX at an extremely reasonable price given the huge development task he subsequently did for me.

Off the record and like Valentin Albillo (Hi Valentin !), I find HP48GX programming extremely cumbersome when compared to HP41 programming. After 2 1/2 years of regular use of HP48GX, I just start feeling comfortable with a basic use of this machine. It certainly has something to do with my “old” age ( I am 53 now ) and maybe with the ( poor ) quality of the HEWLETT PACKARD documentation for the HP48GX while most of the earlier HEWLETT PACKARD Documentation for the HP41 has always been highly regarded and commended as a MODEL in this area.

Starting from his current HP41X/Z Emulator running on HP48(GX), Hrast was able to upgrade it into a most superb HP41X/Y/Z Emulator with the most outstanding features being as follows :

- All my 64K Navigation Software running on the 2 x 32 K Q-ROM Blocks of a RAMBOX II is saved as an “HP41Y” Object on the HP48GX,

- Programs and Data can now be saved to HP48GX and recalled from HP48GX through totally different manners : o Virtual HP41 cards, o Separate HP41 Pages ( any of the 16 pages corresponding to Pages 8 to 16 of either BlockA or BlockB of the RAMBOX II ), o Full 2 x 32 K Q-ROM blocks ( the HP41Y Object on the HP48GX earlier mentionned ), · Transformation of the latter into 16 4K files to be inserted into Jean-François’s EMU41, · HPIL, o and very importantly for me, direct saving of programs listings from HP48GX onto PC/Laptop under .txt format files. ( By the way, through a USB-COM converter, I am now able to connect both ways my HP48 and my Laptop which has 2 USB ports and no COM Ports). Given the equipment I had at hand, saving Programs listings under .txt format files earlier required that such programs be located into an HP41 - meaning that any modified or newly developped program on HP41X/Y/Z had to be manually re-typed on an HP41 Machine - then resent to HP48GX + INPRINT Program through HP41 IR Module, then sent from HP48GX to PC through KERMIT

- I am now using the extensive and incredible Data Exchange Software Hrast developped for FAST DATA TRANSFER between HP48GX-PC, or HP48GX-HP48GX or HP48GX-HP49G !!! This is quite an achievement here compared to some much bulkier software earlier developped by HEWLETT PACKARD for example. Hrast’s software is running at the incredible speed 1 Kbyte/second. As a “cherry on the cake”, I can even now save entire HP48GX 128K Pages, and exchange them onto either PC or another HP48GX !!! Whaooo !!!

- And of course for my HP41X/Y/Z customized version, I do enjoy all standard features of HP41X/Z ( over 3000 RAM registers, over 30 HP41 modules , 3 times the standard HP41 computing speed to name only a few features of this Magic emulator )

Hrast, again I am extremely pleased to CONGRATULATE you in public !!! Your outstanding kindness, friendly and undefective quick reactions as well as everlasting support must be again commended. For me you Hrast are certainly (one of ) the World most extraordinary HP48/HP41 Expert, Wizard and Magician !!!

With my VERY BEST REGARDS to Both of you Jean-François and Hrast

Antoine M. Couëtte

      
Re: WONDERFUL HP41 EMULATORS BY JEAN-FRANCOIS GARNIER AND HRASTPROGRAMMER (long)
Message #2 Posted by Howard Owen on 30 Apr 2006, 4:25 p.m.,
in response to message #1 by Antoine M. Couëtte

That was wonderful to read!

I've used both men's emulators extensively, and have expressed my appreciation for both several times on this forum and elsewhere. But I'm a hobbyist, with no "real" problems to give those wonderful examples of the programmer's art. But you have a real application, which those emulators enhance with their speed and flexibility. That just pleases me, somehow. Thanks for letting us all know about it!

Regards,
Howard

      
RPL vs RPN
Message #3 Posted by Howard Owen on 30 Apr 2006, 4:33 p.m.,
in response to message #1 by Antoine M. Couëtte

Regarding 48g/49g programming, my personal opinion is that the documentation isn't at fault. The inherent complexity of RPL ensures that any complete description of the language is going to read like an encyclopedia. I'm a systems engineer. I first started programming on an HP-41C in 1982 or so. In 2005, it took me six months of intermittent but intense effort to get to the stage where I was comfortable with user RPL. My conclusion, after spending that time, was that RPL is a marvelous environment. But like FORTH and LISP, two of its forebearers, it embodies a peculiar view of the machine; one that may match the hardware better than higher level languages, but also one that makes the process of grasping the language harder for mere humans. This human, at least, had difficulty in doing that. I've heard others claim that they had no such problems starting up with RPL. I'm willing to admit that my training, starting as I did on a 41 all those years ago, may have gotten in my way in learning RPL to some extent. But I think the main difficulties were the sheer size and inherent weirdness of RPL itself. Just my opinion.

Regards,
Howard

            
Re: RPL vs RPN
Message #4 Posted by Thomas Okken on 30 Apr 2006, 8:33 p.m.,
in response to message #3 by Howard Owen

Quote:
But I think the main difficulties were the sheer size and inherent weirdness of RPL itself. Just my opinion.

I've heard plenty of vehement criticisms of, say, the C++ programming language, and of the X Window System, also because of their complexity. The learning curve for both is certainly tough. And yet, both have survived long after some people predicted they would die like a beached whale.

It all comes down to whether you need the power or not, I think. If you do, then you'll learn sooner or later that the complexity is just the unavoidable price of that power. Microsoft Word takes a lot longer to learn than Notepad, but if you need it, you just take a deep breath and make the effort.

What seems to bother a lot of people about RPL is that it makes some common programming tasks harder than necessary -- my own pet peeve is the lack of things like goto, break, and continue, and an easy-to-use debugging facility like the good old R/S and SST. But, on the other hand, I wouldn't dream of writing any majorly complex software on even the HP-42S (my all-time favorite calculator) because the *lack* of structure is going to turn any such endeavor into an intractable mess sooner or later.

- Thomas

                  
Re: RPL vs RPN
Message #5 Posted by Howard Owen on 30 Apr 2006, 10:59 p.m.,
in response to message #4 by Thomas Okken

Hi, Thomas,

Quote:

I've heard plenty of vehement criticisms of, say, the C++ programming language, and of the X Window System, also because of their complexity. The learning curve for both is certainly tough. And yet, both have survived long after some people predicted they would die like a beached whale.


I'm certainly not predicting the death of RPL, although it does seem to be on the ropes, to judge by HP's market share. I don't think that's entirely attributable to RPL's complexity though. But answering what I think you meant by that statement: there are indeed other measures of suitability for computer languages in addition to complexity. I also concede that power and complexity are often directly related, although I think you can fudge the relation if you try hard enough.

I did a quick count just now, and I came up with 29 distinct computer languages that I have learned over the last 22 years. I counted the three assembly languages I know as separate, but lumped together all BASIC dialects but one. That one, Rocky Mountain BASIC was different enough to stand apart, in my opinion. I'm sure I have forgotten several, but not any of the ones I actually did significant work in. I count 17 languages in that category. The point is, I've got pretty broad experience of computer language systems.

With that background, I say RPL costs more in complexity than it yields back in power. I think the main reason for this is the promotion of the stack from important fundamental data structure to the great, central fact of the RPL programmer's life. I think stacks are cool, but so are named variables. I know you can name your variables, and control their scope in sophisticated ways in RPL. But the structure of the language makes it more likely that the accomplished RPL programmer will rip off a sequence with unnamed data, N levels deep on the unlimited stack, keeping track through good visual imagination and excellent memory, or lacking those, pencil and paper. This FORTH-like use of the stack is what gave that language the deserved reputation of a "write-only" system. And it's what makes typical RPL seem so cryptic to me on first, second and many subsequent readings. The postfix nature of things can be gotten used to, and is pretty regular besides. But promiscuous use of anonymous stack data is evil, plain and simple. (This is all IMHO. I know there are other points of view.)

Quote:

It all comes down to whether you need the power or not, I think. If you do, then you'll learn sooner or later that the complexity is just the unavoidable price of that power. Microsoft Word takes a lot longer to learn than Notepad, but if you need it, you just take a deep breath and make the effort.


Well, you could probably have picked a better pair of programs to compare. Word is needlessly complicated, carrying with it the dust of a million weary miles, plus attendant baggage.

Quote:

What seems to bother a lot of people about RPL is that it makes some common programming tasks harder than necessary -- my own pet peeve is the lack of things like goto, break, and continue, and an easy-to-use debugging facility like the good old R/S and SST. But, on the other hand, I wouldn't dream of writing any majorly complex software on even the HP-42S (my all-time favorite calculator) because the *lack* of structure is going to turn any such endeavor into an intractable mess sooner or later.


Points taken. I did say I ended up liking User RPL after working with it for quite a while. I wrote a version of YatZ for the 42 that presented the dice graphically, in the same way as my 71B version does. It was about 1200 lines long. My purpose was to explore the machine's capabilities, so I made little attempt to optimize it. It ran dog-slow on my real 42, unless I enabled the turbo mode. Then it was acceptable. It runs great on Free42, however. 8) I wrote a similar program on the 48g and 49g+. This was the application I used to learn User RPL. It is a lot nicer and runs a lot faster. And that's not just due to the higher clock speed.

The point of that is, the 42 version was a lot of work, due to the fact that the FOCAL implemented on the 42S is pretty low level. The "mother tongue" from the 41 is even more low level, of course. It's flatly amazing what people were able to do with that language. The gentleman whose thread we are hijacking (apologies for that) knows just what miracles are required to get non-trivial programs going on the 41. (A 41CY with lots of RAMBOX memory in this case, apparantly.)

Regards,
Howard

                        
Re: RPL vs RPN
Message #6 Posted by James M. Prange (Michigan) on 1 May 2006, 5:02 a.m.,
in response to message #5 by Howard Owen

Quote:
With that background, I say RPL costs more in complexity than it yields back in power.
I still can't see RPL as being particularly complex. To me, it seems that it's both simple and powerful. Yes, you can make a program quite complex using nested program structures, subprograms, recursive programming, and so on, but you can also make a program quite complex using GOTOs, numbered registers, and so on. To be sure, there are many commands which I don't have the mathematical knowledge to make use of, but in those cases, I don't feel any need to use them. The fundamental programming structures all seem simple and straight-forward to me.
Quote:
I think the main reason for this is the promotion of the stack from important fundamental data structure to the great, central fact of the RPL programmer's life. [\quote] Well, yes, except within algebraic objects, any arguments are taken from the stack, and any results are returned to the stack. Of course, in some cases, the arguments may be placed on the stack from an editing environment, such as the command line editor, matrix writer, or equation writer, or may be recalled to the stack from a variable. What could be simpler? [quote] I think stacks are cool, but so are named variables. I know you can name your variables, and control their scope in sophisticated ways in RPL.
So, if you prefer, minimize your use of the stack by using named local (or even global) variables.
Quote:
But the structure of the language makes it more likely that the accomplished RPL programmer will rip off a sequence with unnamed data, N levels deep on the unlimited stack, keeping track through good visual imagination and excellent memory, or lacking those, pencil and paper. This FORTH-like use of the stack is what gave that language the deserved reputation of a "write-only" system. And it's what makes typical RPL seem so cryptic to me on first, second and many subsequent readings.
Okay, so an "accomplished" RPL programmer may choose to "optimize" his programs for size and/or speed, especially before offering them for general use. For that matter, he may write them in SysRPL or assembly language or, for the 49g+, use HP-GCC, or some combination of the available languages, instead of pure UserRPL, to offer a more "optimal" program or library. Surely this is for the benefit of the user. There's no need for the user to understand the source code of such programs, as long as the user understands what's expected for input and what to expect as output.

After all, I've never looked at the source code for the vast majority of the programs that I use on the PC. Either they work as expected or they don't; I don't try to debug them. I've used Nosy to decompile some commands in the 49 series to try to get ideas of how to write my own programs better, but I don't complain when I don't understand how a command works.

When writing a program for your own use, just use whichever features of RPL seem to work best for you. In my opinion, when a program is for my own use, unless I expect to use it thousands of times, it makes little sense to attempt to optimize it, except perhaps as a programming exercise; doing so would usually take more time than I could expect to recover in reduced execution time. Simply being sure that it works for my own purposes suffices.

Quote:
The postfix nature of things can be gotten used to, and is pretty regular besides.
It seems to me that the postfix nature of RPL is natural for a stack-based language. The general idea is that any result(s) of any operation should be made available for use as the argument(s) of any subsequent operation(s). What better place to take the arguments from than the stack? And if arguments are to be taken from the stack, then it seems to me that the operations have to use postfix notation.

Of course RPL isn't totally postfix; it allows the use of "algebraic objects", in which a function may (depending on the particular function) use prefix or infix notation. But if prefix or infix notation is used, then it seems to me that the argument has to be programmed in or stored in a variable instead of simply being found on the stack.

Quote:
But promiscuous use of anonymous stack data is evil, plain and simple.
Well, you could tag all of the objects on the stack if you wanted to, or make extensive use of named variables, but as long as the programmer knows what his program has put on the stack and taken from it, what's the problem?
Quote:
(This is all IMHO. I know there are other points of view.)
Same here.

Regards,
James

Edited: 1 May 2006, 5:10 a.m.

                        
Thread Hijack ? Re: RPL vs RPN
Message #7 Posted by Antoine M. Couëtte on 1 May 2006, 7:26 a.m.,
in response to message #5 by Howard Owen

****************

The gentleman whose thread we are hijacking (apologies for that) knows just what miracles are required to get non-trivial programs going on the 41. (A 41CY with lots of RAMBOX memory in this case, apparantly.

***************

Thread Hijack ?

Maybe not, finally ... even for a "fast thread reader" ! :-))

When addressing the comparison between the HP41 and 48 programming languages, I knew that I would raise some kind of attention on this "off the record" subject.

My small contribution here would be that for a trained HP41 programmer, I am most lacking a "GTO" feature in the HP48. Maybe it is possible to implement it but ... I just cannot figure out how to do it. :-((

On the other hand the 41 language ( FOCAL ??? ) is not perfect, however it is well adapted to 3 dimensional computations in space.

In my own view, after a few thousands hours spent on programming, refining and debugging programs on the HP41, maybe the best welcome addition to FOCAL would be a 6 level stack ( + Last X of course ) with X, Y, Z, T + A & B for example - with B register automatic replicating of course when the stack goes down - altogether with a complete set of one byte instructions to swap its registers ( Z<>A , T<>X ... ). You can still keep track of 6 level stack and the programming versatility and flexibility would be greatly enhanced.

Best Regards from

Antoine M. Couëtte

                              
Re: Thread Hijack ? Re: RPL vs RPN
Message #8 Posted by James M. Prange (Michigan) on 1 May 2006, 11:10 a.m.,
in response to message #7 by Antoine M. Couëtte

Quote:
Thread Hijack ?

Perhaps, but at least Howard had the good sense to change the subject.

Quote:
My small contribution here would be that for a trained HP41 programmer, I am most lacking a "GTO" feature in the HP48. Maybe it is possible to implement it but ... I just cannot figure out how to do it. :-((

Well, I expect that within a structure clause, maybe it could be done with a new command, but not a GTO out of a clause, at least not in UserRPL. It has to do with the return stack (which the ordinary user doesn't need to be aware of); it seems to me that a GTO would risk leaving pointers "stranded" on the return stack, which would be found the next time anything was popped off of the return stack, making a total mess of things. It seems to me that allowing a GTO out of a clause would require redesigning RPL into a completely different language. The UserRPL compiler enforces the syntax for program structures, to ensure that (among other things) you clean up the return stack properly. I expect that you just have to learn to use the program structures instead of GTO in UserRPL.

SysRPL offers commands for manipulating the return stack, so it just might be possible there, although it doesn't seem to me to be a good idea.

In Saturn assembly language, GOTO (and GOLONG, GOVLNG, GOC, GONC, and GOYES) is possible, and indeed seems essential for programming anything of much complexity, because of the lack of program structures.

With the MASD compiler, you can avoid using the various GO* and RT* instructions by using "blocks" with the various SKIP pseudo-instuctions in the source code; a block can contain various UP and EXIT pseudo-instructions, and the blocks can be nested, but these compile to the same object code as using the equivalent GO* and RT* instructions and labels. It seems to me that the only advantage to the blocks and such would be that some programmers may find them easier to understand; personally, I'd rather skip the SKIP pseudo-instructions.

But I suppose that I'm being inconsistent here; after all, the blocks and such are supposed to offer structured programming, and I suppose that MASD enforces proper syntax with them. I guess that maybe I just don't like the idea of using a mixture of blocks and GO* instructions; perhaps if I learned to use just the block structures without any GO* and RT* instructions and labels at all, I might be able to get used to it. But decompiling always results in the native Saturn GO* and RT* instructions and (numeric) labels, so I suppose that I'd still want to be quite familiar with them.

Of course a GOSUB for even UserRPL wouldn't be difficult, as the compiler could require a matching RETURN, but subprograms are very easily used within RPL programs without any need for GOSUB and RETURN commands, so there wouldn't seem to be any point to a GOSUB instruction in RPL.

Regards,
James

Edited: 1 May 2006, 11:16 a.m.

                                    
Re: Thread Hijack ? Re: RPL vs RPN
Message #9 Posted by James M. Prange (Michigan) on 1 May 2006, 11:23 a.m.,
in response to message #8 by James M. Prange (Michigan)

PS:

On the 49g+, you can also program in the C language by using HP-GCC.

Since the flash "ROM" can be rewritten on the 49G and 49g+, you could, in principle, replace the built-in RPL with your own operating system.

Regards,
James

                        
Re: RPL vs RPN
Message #10 Posted by Cameron Paine on 1 May 2006, 8:52 a.m.,
in response to message #5 by Howard Owen

Fascinating. I'm enjoying this thread very much. Largely because the contributions are weighty and have shed much light on a topic that I find interesting.

Let me take up a point first made by Thomas:

Quote:
[M]y own pet peeve is the lack of things like goto, break, and continue...

Howard seems to concur and then adds:

Quote:
[The] promiscuous use of anonymous stack data is evil, plain and simple.

I subscribe to the school of thought that holds that "anonymous" flow control statements are at least as evil as anonymous data. I arrived at this position because the experiental evidence available to me (over 25 years) suggests that maintainers will often break (pun intended) code because they failed to understand the control flow that was obscured by short-circuits like break and continue. Similarly, maintainers will often use these constructs to "fix" code which is subsequently broken by the next generation's maintainer.

In such instances, post-breakage analysis suggests that refactoring the control structure(s) might have been more robust and productive. Which leads to the conclusion (I'm skipping most of the beef) that break, continue and goto are to be avoided whenever possible.

I'd be grateful if you chaps could expand on the counter POV in the context of the discussion of RPL vs RPN. This isn't a troll: I'm interested in the reasoning behind your position(s).

Incidently, the break in C/C++ case statements is a syntactic turd and is not what I'm talking about here. There is a separate (but similar) position that maintains that falling through from one case handler to another is evil. I don't usually embrace this position. ;-)

Cameron

                              
Re: RPL vs RPN
Message #11 Posted by Thomas Okken on 1 May 2006, 2:06 p.m.,
in response to message #10 by Cameron Paine

Quote:
maintainers will often break (pun intended) code because they failed to understand the control flow that was obscured by short-circuits like break and continue.

No system is immune to careless programmers! Removing features, or banning their use, just because some programmers get them wrong, seems an awful lot like banning cars because some people can't drive...

- Thomas

                  
Re: RPL vs RPN
Message #12 Posted by James M. Prange (Michigan) on 1 May 2006, 5:39 a.m.,
in response to message #4 by Thomas Okken

Quote:
What seems to bother a lot of people about RPL is that it makes some common programming tasks harder than necessary
Or maybe a lot of people make such common programming tasks seem harder than they really are in RPL?
Quote:
-- my own pet peeve is the lack of things like goto,
Well, I agree that GOTO could be useful, but in RPL it would have to be restricted to jumps within a programming structure clause, which would limit its usefulness.
Quote:
break, and continue,
Do you mean things like the commands HALT (or PROMPT. INPUT, KEY, WAIT, etc.) and CONT?
Quote:
and an easy-to-use debugging facility like the good old R/S and SST.
What's wrong with the built-in UserRPL debugging facility?

Regards,
James

Edited: 1 May 2006, 5:44 a.m.

                        
Re: RPL vs RPN
Message #13 Posted by Thomas Radtke on 1 May 2006, 6:51 a.m.,
in response to message #12 by James M. Prange (Michigan)

Quote:

Quote: break, and continue,

Do you mean things like the commands HALT (or PROMPT. INPUT, KEY, WAIT, etc.) and CONT?


I think he's refering to the C implementations of them. I have tried to discuss this issue here and on usenet but to not much avail. IMHO, the omission is a major flaw in RPL but most people don't mind. Thats a bit disturbing;).

Thomas

                              
Re: RPL vs RPN
Message #14 Posted by James M. Prange (Michigan) on 1 May 2006, 8:08 a.m.,
in response to message #13 by Thomas Radtke

Quote:
I think he's refering to the C implementations of them.

Oh, okay. I thought that he must've been referring to some arcane commands in "Classic RPN".

Well, in a C case statement, I guess that break simply jumps to the end of the switch statement, much like any true flag for a THEN in an RPL CASE structure jumps to the end of the structure after executing the THEN clause. And in a loop, the C break simply forces an exit from the loop.

The C continue seems to be simply for jumping directly to the test clause in a loop.

Quote:
I have tried to discuss this issue here and on usenet but to not much avail. IMHO, the omission is a major flaw in RPL but most people don't mind. Thats a bit disturbing;).

Well, I can see that break and continue might be useful in RPL, but I can't see their ommision as a "major flaw in RPL" by any stretch of my imagination. After all, except in a START loop, what can you do with them that you can't accomplish easily enough without them? And for the START loops, you can simply use a FOR loop and ignore the index variable instead.

Regards,
James

                                    
Re: RPL vs RPN
Message #15 Posted by Thomas Radtke on 1 May 2006, 9:19 a.m.,
in response to message #14 by James M. Prange (Michigan)

Quote:
[...] what can you do with them that you can't accomplish easily enough without them?
Right, but since the text window is very limited on 48/49 calcs, I dislike any additional 'if' clauses neccessary only to compensate for some statements easy enough to implement. That might only be me as I'm easily lost in the source code when I can see only a small fraction of it. Thats what I meant when talking about my disturbance. Accepting that is harder than blaming HP for not implementing those keywords. Sorry;).

Thomas

                                    
Re: RPL vs RPN
Message #16 Posted by Howard Owen on 1 May 2006, 12:17 p.m.,
in response to message #14 by James M. Prange (Michigan)

The C keywords break and continue are principally useful in data processing loops, where you want to respond to input by terminating processing or skipping part of the processing. My main language is Perl, and it has a richer set of operators for doing that sort of thing:

    keyword       function
    -------------------------------------------------
    next          go to next loop iteration
    last          exit loop (break)
    continue      skip to continue block
    redo          restart loop without reevaluating
                  loop control statement

The continue block, if present, contains code that is executed just before the loop control statement is evaluated. In the absence of next, last or continue statements, it is just the tail end of your processing block. Here's and example with while, although these keywords can be used in any Perl block:

while (<IN>){ # <IN> reads a line from the IN filehandle into # the $_ variable. Returns false at EOF

last if (/deadly pattern/); # exit loop if (/^first pattern/){ do { some_first; pattern_things; } continue; # skip to continue block } if (/^pattern/){ # a more general pattern next if (/uncool stuff/); # jump to continue block do_cool_stuff; } } continue { # Executed before the next loop update_some_generic state_variables; # Line counters, e.g. }

These are all somewhat structured equivilants to goto. That statement is not to everyone's taste. But to my mind, these constructs give you enhanced control to create loops as you like. I try to use that flexibility to accomplish two things. First, I try to make my scrupts readable, and therefore maintainable. Second, I try to make them efficient. I use next and last extensively, and continue less often, and redo almost never. They tend to match the sort of things you need and want to do with sequential processing of text. Lack of these constructs doesn't make such processing impossible, just harder, and needlessly complicated.

Regards
Howard

      
Previous thread on celestial navigation software
Message #17 Posted by Karl Schneider on 1 May 2006, 12:02 a.m.,
in response to message #1 by Antoine M. Couëtte

Antoine --

Good to hear from you again! I remember that you had posted a few times in a lengthy thread on celestial naviagtion software, that contained extensive contributions from Valentin Albillo. (I got one post in there, touting Tom Sherman's program for the HP-41, which I run on a near-daily basis.)

Here's the thread from 2004 (focused on your main post):

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv014.cgi?read=58531#58531

-- KS

            
Re: Previous thread on celestial navigation software
Message #18 Posted by Antoine M. Couëtte on 1 May 2006, 6:01 a.m.,
in response to message #17 by Karl Schneider

Hello Karl,

Thank you for your kind reminder of an earlier contribution I had made in a subject related to celestial Navigation.

I earlier stated in this thread :

************************

"With the main exception being Jean Meeus's publications, I have often noticed that accuracies versus validity time frames are seldom adequately covered ( if ever adressed ) in a number a celestial publications related to disseminating astronomical data to a wide variety of users."

************************

This still seems true for most of the "non professionnal" software publicly available.

I you really want accurate LONG-Term validity (+/- 1000 years around 2000.0) data for Celestial Navigation, given the complexity of the mutual planetary perturbations, you cannot end up with less than 7000 bytes on an HP41 just for Saturn, or @ 6000 Bytes for Jupiter or the Moon, and almost 4000 bytes fot the Sun itself. By the way the Sun itself needs to be computed at an accuracy beter than 1 arc second - I chose to compute its position at 1/2 arcsecond - simply for geometrical considerations related to planetary positions computations ( Mainly Vanus and Mars when they are closest to the Earth ) .

Best Regards

Antoine

            
Re: Previous thread on celestial navigation software
Message #19 Posted by Geir Isene on 1 May 2006, 9:56 p.m.,
in response to message #17 by Karl Schneider

I got Tom's program from him (scanned) and will ask for permission to publish it as a pdf.

I also modified it so that the user can enter any arbitrary date and time (not just taken from the current date and time set in the calculator). It also asks for Time Zone and Summer Time and will adjust for these. If ok by Tom, I will publish this on UC-41.

                  
Tom Sherman's HP-41 celestial navigation program
Message #20 Posted by Karl Schneider on 2 May 2006, 12:51 a.m.,
in response to message #19 by Geir Isene

Hello, Geir --

Yes, I had similar ideas for some modest improvements to the program. Being able to enter an arbitrary date and time is useful, not only to run for future or past events, but also because not everyone has a 41CX or a Time Module. The program would also be more portable to the HP-42S without a need to obtain present time.

However, if code is added for the user to input date and time, the code should perform error-checking. The user should have the option of simply using the date and time from the clock (if available), and should allow application of a local time-zone correction to UCT (GMT). All of this adds size the program.

I'd like the program to run faster, and not to run in a continuous loop. There seems to be lengthy processing upon starting the program that perhaps could be avoided.

One hint: The user need not confirm the latitude and longitude values every time. A, B, C, F, G, H, or I can be selected at the first opportunity to calculate the object's position (or J to display the menu).

The program does not calculate the position of Mercury, Uranus, Neptune, or Pluto. While recognizing that Tom's program relies upon the Navigation Pac routines, those who are more knowledgable (or Tom himself) might explain why.

Regards,

-- KS

Edited: 2 May 2006, 1:32 a.m.

                        
Re: Tom Sherman's HP-41 celestial navigation program
Message #21 Posted by Tom Sherman on 2 May 2006, 3:51 p.m.,
in response to message #20 by Karl Schneider

Thanks, Karl and Geir, for your kind words and interest in the "Sky Map and Compass" program for the HP-41CX (or 41CV with Time Module). Geir's modification to allow for manual entry of time and date is a nice improvement, and it will be good to have his improved version of the program available at his website. Many years ago, someone telephoned me from the San Diego Yacht Club asking whether the program could be used without the time module. It had been about ten years since I wrote the program, but I tried without a copy of it in front of me to describe what he had to do to enter time and date manually. When I had finished, he said "I think I'll just buy the time module!" Now, thanks to Geir, any future users will have a choice.

The program merely allows the user of the Navigation Pac to put its astronomical formulas (Perpetual Almanac) and spherical trigonometry formulas (Sight Reduction Table) together in an automated and convenient way. The astronomical formulas predict the celestial coordinates of the bodies, and the spherical trigonometry formulas convert the celestial coordinates to local coordinates of altitude and azimuth.

The reason that Mercury, Uranus, Neptune, and Pluto are left out is because HP decided to make a Navigation Pac rather than an Astronomy Pac, and since those planets are of no use to the navigator, astronomical formulas for them were not included in the Navigation Pac. Since my cookbook program just makes use of ingredients provided by HP, those planets had to be left out of my program, for lack of their astronomical formulas.

Cheers, Tom

                        
Re: Tom Sherman's HP-41 celestial navigation program
Message #22 Posted by Geir Isene on 2 May 2006, 3:54 p.m.,
in response to message #20 by Karl Schneider

The following is a version 0.4 of the modified program. Please give me feedback so thet we can get it (as) perfect (as possible) before I make a full write-up and put it out on UC-41.

The documentation for Tom's program is the basis.

The labels are shown (in short form) in the menu. The labels goes like this:

LBL A - SUN
LBL a - VENUS
LBL B - MOON
LBL b - MARS
LBL C - STAR
LBL c - JUPITER
LBL d - SATURN
LBL E - Back to the menu
LBL e - Restart the program

Upon execution, the program asks for date and time ("now" is the default, mening it will take the time from the time module).

It will then ask for the time zone and wether then if there is summer time. Then it asks for latitude and longitude.

Then the menu shows.

If after calculating the position of one object, the user can just hit "e" to go back to the menu (without having to reenter the initial data) or press "E" if any of the initial data is to be corrected.

Also, the program is no longer automatically continous. The program will halt after the initial displaying of alt./azi. If the user then presses R/S, it will go into the continous mode.

Here's the program:

001 *LBL "SKY"
002  LBL e
003  CF 01
004  CF 02
005  SF 00
006  CLK24
007  "DT^TM= <NOW>"
008  CF 22
009  PROMPT
010  FC? 22
011  GTO 10
012  STO 55
013  X<>Y
014  FS? 31
015  XEQ "DMD"
016  STO 30
017  SF 02
018  LBL 10
019  RCL 54
020  "TZ= "
021  ARCL X
022  PROMPT
023  STO 54
024  "N"
025  ASTO Y
026  "SUM.TIME? <"
027  FS? 03
028  "|-Y"
029  FC? 03
030  "|-N"
031  "|->"
032  CF 23
033  AON
034  PROMPT
035  AOFF
036  FC? 23
037  GTO 11
038  ASTO X
039  X NE Y?
040  SF 03
041  LBL 11
042  RCL 07
043  "LAT"
044  XROM "DSPL"
045  "|-?"
046  PROMPT
047  XROM "*HR"
048  STO 07
049  RCL 08
050  "LO" 
051  XROM "DSPLO"
052  "|-?"
053  PROMPT
054  XROM "*HR"
055  STO 08
056  LBL E
057  "S,V O,M *,J ,SA"
058  PROMPT
059  LBL A
060  "SUN"
061  AVIEW
062  3
063  LBL 03
064  XEQ 01
065  ,012
066  +
067  STO 34
068  XROM "*SUN"
069  GTO 02
070  LBL B
071  "MOON"
072  AVIEW
073  4
074  LBL 04
075  XEQ 01
076  ,026
077  +
078  STO 34
079  XROM "*MOON"
080  GTO 02
081  LBL C
082  "STAR NO= ?"
083  PROMPT
084  INT 
085  STO 47
086  FIX 0
087  "STAR "
088  ARCL 47
089  AVIEW
090  5
091  LBL 05
092  XEQ 01
093  ,011
094  +
095  STO 34
096  RCL 30
097  XROM "FA"
098  STO 44
099  XROM "*STAR"
100  GTO 02
101  LBL a
102  "VENUS"
103  AVIEW
104  6
105  LBL 06
106  XEQ 01
107  ,017
108  +
109  STO 34
110  XROM "*VENUS"
111  GTO 02
112  LBL b
113  "MARS"
114  AVIEW
115  7
116  LBL 07
117  XEQ 01
118  ,019
119  +
120  STO 34
121  XROM "*MARS"
122  GTO 02
123  LBL c
124  "JUPITER"
125  AVIEW
126  8
127  LBL 08
128  XEQ 01
129  ,02
130  +
131  STO 34
132  XROM "*JUPIT"
133  GTO 02
134  LBL d
135  "SATURN"
136  AVIEW
137  9
138  LBL 09
139  XEQ 01
140  ,024
141  +
142  STO 34
143  XROM "*SATUR"
144  GTO 02
145  LBL 01
146  STO 56
147  RCL 55
148  FS? 02
149  GTO 12
150  DATE
151  FS? 31
152  XEQ "DMD"
153  STO 30
154  TIME
155  LBL 12
156  RCL 54
157  HMS-
158  FS? 03
159  1
160  FS? 03
161  HMS+
162  HR
163  RTN
164  LBL 02
165  RCL 44
166  RCL 45
167  +
168  RCL 08
169  -
170  RCL 07
171  RCL 46
172  XROM "*SRT"
173  CF 21
174  BEEP
175  FIX 1
176  "ALT= "
177  ARCL X
178  AVIEW
179  PSE
180  PSE
181  "AZI= "
182  ARCL Y
183  AVIEW
184  FC? 01
185  STOP
186  SF 01
187  GTO IND 56
188  END
                              
Re: Tom Sherman's HP-41 celestial navigation program
Message #23 Posted by Karl Schneider on 4 May 2006, 1:01 a.m.,
in response to message #22 by Geir Isene

Geir --

Thanks! I programmed your enhancement yesterday, and have tried it. I need some more time to provide feedback.

-- KS

      
Re: WONDERFUL HP41 EMULATORS BY JEAN-FRANCOIS GARNIER AND HRASTPROGRAMMER (long)
Message #24 Posted by HrastProgrammer on 1 May 2006, 12:46 a.m.,
in response to message #1 by Antoine M. Couëtte

Hi Antoine,

Thank you very much for your kind words :-)

It was a pleasure to work with you for the last 30 months. And certainly, some HP-41X features wouldn't be developed without your help and HP-41X wouldn't be tested to such high level as it is now.

Good luck with your flights! I hope that HP-41X will serve you well in the future ...

I would also like to congratulate Jean-Francos for his extraordinary Emu41, Emu42 (yes, JFG developed one, too) and Emu71 emulators. Theye were of invaluable help when I was hunting some HP-41X/42X/71X bugs ...

Best regards.
Hrast

            
Re: WONDERFUL HP41 EMULATORS BY JEAN-FRANCOIS GARNIER AND HRASTPROGRAMMER (long)
Message #25 Posted by Antoine M. Couëtte on 1 May 2006, 8:14 a.m.,
in response to message #24 by HrastProgrammer

Hrast,

After the first programs saving by Jean-François, which was a necessary task - since I was by no means ready to retype every single instruction on a set of 35000 + - you are the man who made my software work on an HP48 GX !!! I have always needed a HANDHELD. At the expense of very slow computing speed when compared to EMU41 - I can conveniently take my Handheld anywhere on board a ship, or in the cockpit ....

So Thank you again and CONGRATULATIONS

Antoine

----------

Note : Unfortunately in my initial message on top of this current Thread, I did not correctly "copy - paste" the very important information on your fantastic FAST DATA EXCHANGE SOFTWARE. Its use has made a huge difference to me. Again you wrote here an extremely simple and user friendly software running at 1 Kb/ second, which is very much more convenient and faster than the ealier KERMIT version I had been using before.

For interested users, here it is again this information better formatted here-below :

******

Starting from his current HP41X/Z Emulator running on HP48(GX), Hrast was able to upgrade it into a most superb HP41X/Y/Z Emulator with the most outstanding features being as follows :

- All my 64K Navigation Software running on the 2 x 32 K Q-ROM Blocks of a RAMBOX II is saved as an “HP41Y” Object on the HP48GX,

1 - Programs and Data can now be saved to HP48GX and recalled from HP48GX through totally different manners :

1.1 - Virtual HP41 cards,

1.2 - Separate HP41 Pages ( any of the 16 pages corresponding to Pages 8 to 16 of either BlockA or BlockB of the RAMBOX II ),

1.3 - Full 2 x 32 K Q-ROM blocks ( the HP41Y Object on the HP48GX earlier mentionned ),

1.4 - Transformation of the latter into 16 files of 4K each to be inserted into Jean-François’s EMU41,

1.5 - HPIL,

1.6 - And very importantly for me, direct saving of programs listings from HP48GX onto PC/Laptop under .txt format files. ( By the way, through a USB-COM converter, I am now able to connect both ways my HP48 and my Laptop which has 2 USB ports and no COM Ports). Given the equipment I had at hand, saving Programs listings under .txt format files earlier required that such programs be located into an HP41 - meaning that any modified or newly developped program on HP41X/Y/Z had to be manually re-typed on an HP41 Machine - then resent to HP48GX + INPRINT Program through HP41 IR Module, then sent from HP48GX to PC through KERMIT.

1.7 - As a “cherry on the cake”, I can even now save entire HP48GX Pages of 128K, and exchange them onto either PC or another HP48GX !!! Whaooo !!!

- I am now using the extensive and incredible Data Exchange Software Hrast developped for FAST DATA TRANSFER between HP48GX-PC, or HP48GX-HP48GX or HP48GX-HP49G !!! This is quite an achievement here compared to some much bulkier software earlier developped by HEWLETT PACKARD for example. Hrast’s software is running at the incredible speed 1 Kbyte/second !!! Whaooo !!!

******

      
Re: Thanks, Antoine
Message #26 Posted by J-F Garnier on 1 May 2006, 6:37 a.m.,
in response to message #1 by Antoine M. Couëtte

Thanks Antoine !

I remember when you came at home to save the content of your trusty but tired HP41CY!

Saving the 16 pages of your RAMBOX was a little bit tricky, because you removed the W&W OS (you really needed the full 64k space!) and we had to plug a extra module containing the OS (a special version, dedicated to your own needs) to save each page of each block in turn.

I indeed developed the RAMBOX II (or CY) emulation following your visit, to help you but also because it was a challenge to make your software running on my emulator, finally to the benefit of all Emu41 users. I discreetly alluded to you when I announced the RAMBOX emulation ( see here ).

Let me in turn highlight the great piece of work Antoine made with his AstroNav software. Not only is it a high performance, high precision Astronomical software based on the lastest theories of the time, but the implementation on the HP-41 is a piece of art by itself! Just look: 64k of user code, with only the few necessary microcode bank switching functions, jumping from one bank to another in a way that even W&W didn't expect to be possible! This is really by far the largest and the most complex HP-41 user software I ever saw. I hope that someday Antoine will be able to make it available to all.

My best regards,

Jean-Francois

(Hi Hrast, nice to have some news from you!)

Edited: 1 May 2006, 6:57 a.m.

            
Re: Thanks, Antoine
Message #27 Posted by Antoine M. Couëtte on 1 May 2006, 7:47 a.m.,
in response to message #26 by J-F Garnier

Quote:
I hope that someday Antoine will be able to make it available to all.

Hi Jean-François,

This very nice story would never had continued onto future had you not been able to save all 16 pages from my shaky HP41CY TURBO to your Computer through some kind of magic operations to me !!!! Thank you again !!! And again congratulations on EMU41 !!!

As making this software available to the Community, I first need to write a User's Manual. Still a project for the past 3 years. But now with the free time I have - 2 days in Madras, 2 days in Houston, 1 or 2 days in Gander , 1 day in Milan , :-))) .... - between my flights, it is my intention to start writing it up soon.

And obviously, as my ASTRONAV software can now be available only through HP41X/Y/Z any interested user would first need to purchase HP41X/Y/Z from HrastProgrammer.

Best Regards

Antoine

                  
Re: Thanks, Antoine
Message #28 Posted by Antoine M. Couëtte on 1 May 2006, 2:24 p.m.,
in response to message #27 by Antoine M. Couëtte

... and obviously ASTRONAV can run on EMU41 also.

I am planning to release ASTRONAV when the User's Manual is ready.

Antoine

                        
Re: Thanks, Antoine
Message #29 Posted by Howard Owen on 1 May 2006, 5:26 p.m.,
in response to message #28 by Antoine M. Couëtte

By way of encouragement, let me say that I would love to see your code, Antoine! I have no need to do celestial navigation, but a 41C program of that size would be really interesting to look at, purely from a software engineering point of view. I'm sure you will announce its availability here. I look forward to that day! 8)

Regards
Howard

                              
Re: Thanks, Antoine
Message #30 Posted by Antoine M. Couëtte on 3 May 2006, 3:36 a.m.,
in response to message #29 by Howard Owen

Thanks Howard for your kind comment.

When my User's Manual for my 64K Celestial Navigation Software for HP41 is ready I will definitely announce it on this forum.

I am also considering to release this User's Manual on the Internet, as a free access document while the ASTRONAV Software itself would be sold at reasonable price. Would this be a good idea ?

Best Regards

Antoine


[ Return to Index | Top of Index ]

Go back to the main exhibit hall