WONDERFUL HP41 EMULATORS BY JEAN-FRANCOIS GARNIER AND HRASTPROGRAMMER (long)



#4

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


#5

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

#6

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


#7

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


#8

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


#9

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.

#10

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

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


#11

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.


#12

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

#13

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


#14

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

#15

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.


#16

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


#17

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


#18

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

#19

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

#20

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


#21

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

#22

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.


#23

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.


#24

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

#25

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

#26

Geir --

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

-- KS

#27

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


#28

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 !!!

******

#29

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.


#30

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


#31

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

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

Antoine


#32

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


#33

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


Possibly Related Threads...
Thread Author Replies Views Last Post
  A Wonderful Classic HP Calculator BShoring 2 772 11-22-2013, 05:25 PM
Last Post: BShoring
  HP Prime: Long integers (continued) Helge Gabert 2 806 11-07-2013, 11:24 AM
Last Post: Helge Gabert
  HP Prime: Pass "Long" Integers to a Program Helge Gabert 6 1,350 11-03-2013, 01:12 PM
Last Post: Helge Gabert
  HP Prime polynomial long division bluesun08 13 1,971 10-30-2013, 03:29 AM
Last Post: parisse
  Emulators Olivier De Smet 5 984 06-23-2013, 09:52 AM
Last Post: Olivier De Smet
  any open source HP 10BII emulators? John 15 2,356 06-12-2013, 09:58 AM
Last Post: Kimberly Thompson
  Selftest of HP-15C in 'emulators' of it Mike (Stgt) 1 599 06-06-2013, 04:27 AM
Last Post: Mike (Stgt)
  Emulators for iOS on sale today Bruce Bergman 3 895 05-24-2013, 03:54 PM
Last Post: BShoring
  New WP34s Emulators with better display pascal_meheut 13 1,827 04-24-2013, 02:32 PM
Last Post: RalfGeiger
  A very long HP-17BII equation Gerson W. Barbosa 22 3,052 04-19-2013, 12:37 AM
Last Post: Gerson W. Barbosa

Forum Jump: