Programming RPN on the 48?



#2

Ive been reading more aboutthe HP 48. I had one for a week before it got stolen in ~1992, so I never had time to get comfortable with it. Being a geek I then went on specs and replaced it with a 49g+ which has sat in a drawer ever since.

Looking back at the HP 48G, it seems to have more functions on the keyboard, and a lovely design.

Im not ready to evaluate RPL vs RPN, but I am enjoying RPN on my 35s. Can the 48's RPL be ignored and programmed RPN? If thats the case, why would you use a 42s?

Daniel.


#3

Quote:
Can the 48's RPL be ignored and programmed RPN?

No. The 48 is RPL only.
#4

Daniel,

The 48 machines (and successors) do not support RPN. They offer RPL.

RPN and RPL while similar in certain aspects are different in many others. Both use stacks. RPN machines have had 4-level stacks as designed by HP. RPL uses a dynamic stack (in both the number of levels and the contents of each level) and uses its more intensely than RPN. For example in RPN you can use the command STO 0 to store the contents of the X-register to memory register 0. In RPL you have a value at level 1 that you want to store. You push the name of the recipient variable, say 'X', into the stack and then execute the STO command. That command takes its destination from level 1 and the value to store in level 2. After you execute the STO command in RPL, the original values in levels 1 and 2 are consumed by the STO command and the stack drops by 2 levels. In other words the value you wanted to store no longer appears in the stack. This is quite different from a STO in RPN which leaves the value to be stored on the stack. To mimic RPN's behavior in RPL, you need to first issue a DUP command to duplicate the value in level 1, push the name of the target variable into the stack, and then execute STO. The result is that level 1 now has the value that you stored, and variable 'X' also stores that value.

This is a simple example on how RPN and RPL differ. One noteworthy difference to mention is that RPL can declare local variables in the blocks of code contained in pairs of << and >> characters. RPN lacks the feature of local variables, making the creation of reusable program objects more difficult.

Namir


Edited: 7 Sept 2011, 2:37 a.m.


#5

I think that a major difficulty for those who came from RPN and then uses RPL is the lack of GOTO function. RPL is a strongly structured language and RPN not. RPL is far more powerfull but more complex to learn (not sure of that for simple RPL programs). Imho there is no possible comparaisons between them. But the best tools (language) are those wich permit to solve easily your problems.

It would probably be impossible (and heretic ! ) to have GOTO / LBL instructuctions in RPL, but this could help people who have problems with structured language. I'm quite sure that people who like RPN and not RPL would have another views if they could use some GOTOs and LBLs in RPL.


Edited: 7 Sept 2011, 7:53 a.m.


#6

The RPN to RPL relationship is roughly the same as is BASIC to PASCAL. In RPN, as in BASIC, its easy to start writing simple programs but creating more involved code quickly gets unhandy.

RPL is well structured, has powerful control statements and lacks GOTO, very similar to PASCAL. It is a bit of a hurdle to begin writing software with it but the results have more potential of being cleanly structured, easily expandable and correct.

Maybe RPL is more like FORTH for some. You can do everything on the stack which makes some RPL programs look "write only". It's possible to do so and it's efficient (code and speed wise). If you have the need to look after your programs some time later, a more defensive approach at compactness may be the better approach.


#7

The lack of Goto becomes quite annoying when you need to break out of a loop. You can always do it, of course, by adding more structures, but that seems like overkill for the problem.

I've seen some people recommend loop breaking with error trapping, but I wish there was a more "normal" way of doing it.


#8

I agree at 110% ;). But no needs of GOTO for that : It just miss something like a BREAK or EXIT command in RPL (this exists in many language, like Pascal ...). The use of "error trapping" is not natural and very slow. This lack is very annoying in some cases..


Edited: 7 Sept 2011, 11:14 a.m.


#9

Yeah. It has KILL, which works if you only want to break out of one level of program. But if another program CALLS a program that has KILL in it, KILL will kill even the parent program.

#10

Quote:
RPL is well structured, has powerful control statements and lacks GOTO, very similar to PASCAL.

Pascal has GOTO.

It was in every Pascal I used (last was over 10 years ago) and is defined in ISO 7185 from 1982 and even in the 1973 language summary which Wirth referred to several times as standard Pascal.


#11

I worked a lot in Pascal UCSD then Turbo Pascal then Delphi in the past and don't remember at all any GOTO ... Perhaps Tubo/Delphi are not ISO compatible but even if it is possible, I never imagined use a GOTO in Pascal. Seems like an horror for me ;)

Searching for "Goto in Pascal" I found this:

"Software is getting slower more rapidly than hardware becomes faster."
Niklaus Wirth's law

Edited: 7 Sept 2011, 5:27 p.m.


#12

And its the interaction between Moore's Law and Wirth's Law that will prevent the "Singularity" from ever happening.

#13

Quote:


Pascal has GOTO.


While it's true that Pascal has goto, if I remember correctly (it's been a few years) the target of the goto has to be a numeric label. So you have to write things like

goto 100;

rather than

goto lastditcherrorhandler;

which would be more meaningful. I always got the impression Wirth was a bit mean-spirited over that; he would let you write non-structured code, but if you did, he would punish you for it and make it as painful as possible so you'd learn your lesson.

Best,

--- Les

[http://www.lesbell.com.au]


#14

Quote:


... and make it as painful as possible so you'd learn your lesson.


It was a teaching language after all. :)

#15

Quote:
While it's true that Pascal has goto, if I remember correctly (it's been a few years) the target of the goto has to be a numeric label. So you have to write things like

goto 100;


Having grown up on FORTRAN and BASIC, the above seems entirely normal to me!
#16

Quote:
I always got the impression Wirth was a bit mean-spirited over that; he would let you write non-structured code, but if you did, he would punish you for it and make it as painful as possible so you'd learn your lesson.

The use of the goto statement per se does not imply non-structured codes. Actually the first PASCAL programs I wrote in 1984 used labels at the beginning of every structure (010, 020, 030...) as per teacher's recommendation. Our textbook was Jean-Dominique Warnier's Logical Construction of Programs (LCP). We learned all other PASCAL statements later and goto was never needed again. Our professor's intention was making his students able to write structured code, no matter the programming language they used.

Gerson.


Edited: 7 Sept 2011, 10:44 p.m.


#17

Quote:
The use of the goto statement per se does not imply non-structured codes. ... Our professor's intention was making his students able to write structured code, no matter the programming language they used.

Exactly.

Once you have conditional's and goto you have the beginnings of structure and you can fake the rest.

It can be quite helpful if you have at least one level of subroutine, and having many levels helps a bit more.

But even more useful than a subroutine is to have local variables.

For a time I had to maintain and enhance a large program written in an "advanced" BASIC. It's only advanced feature for the time was optional line numbers but it did have goto {variable}. No gosub/return, no local variables, and only 6 char variable names. The "main" and all subroutines had to use defined variable names to avoid clobbering each other's variables. And each subroutine had a "goto RVAR00" at the end. The caller would save the previous contents of RVAR00 and set RVAR00 to the proper line number for the ending 'goto' to return from the subroutine. But our code was structured and that made it much more maintainable.

#18

Quote:
The use of the goto statement per se does not imply non-structured codes.

In that era, and still today, it certainly does. Edsger Dijkstra's paper, "Go To Statement Considered Harmful" (see [url:http://www.google.com/url?sa=t&source=web&cd=2&ved=0CCcQFjAB&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.92.4846%26rep%3Drep1%26type%3Dpdf&ei=UshoTu3QMsmpiAeMqKnHCw&usg=AFQjCNEjry3w6PN-Lb9yWUlwZHC6prLPGg&sig2=J7wb2OmxsCkmjqB3ZL7_iQ]) had led to the Structured Programming movement, which was intended to stamp out the goto. That's what Structured Programming is: programming with a somewhat restricted set of control flow statements, especially no goto's [1].

I tried it out for myself, implementing a large subset of the dBASE language in approximately 70 modules (of PL/I code) without a single goto, and realised that it pretty much worked - only one bug was ever found in my code, although it only took three days to write. On the other hand, there are times when you find yourself many levels deep in subroutines with no exception handling, and goto is the ideal tool for the job, so I favour its retention.

These days, the purists restrict themselves even more, with functional programming. Who needs while loops, when you've got recursion and the lambda calculus? ;)

Best,

--- Les

[http://www.lesbell.com.au]

[1] http://en.wikipedia.org/wiki/Structured_programming

#19

my 2 (euro)cents

The major problem of RPL, IMHO, is lack of orthogonality and presence of many functions, which are not needed. Many high level languages, especially designed by Niklaus Wirth, have very concise and elegant syntax, while RPL has very cumbersome and complicated one.

Compared to RPL, RPN could be assumed to be assembler-like, but good assembler/instruction set (like DEC's PDP-11) is much more easier to program than overloaded, unsymmetrical, non-orthogonal high-level language. When high-level control structures are combined with giant set of assembler-level primitives, we get DUP2, DROP2 and other weird beauties. It seems as if RPL designers put everything of a kind in the box, trying to adhere to the latest programming technology trends.

Personally, I think RPL is very awkward and unelegant language. Learning curve is so steep not because RPL is powerful, but because it is ill-designed. However, it IS the most powerful calculator language available now, so there is no choice yet.

Maybe, there is a fundamental problem of designing programming language with stack structure. Stack languages are rather rare, but some of them (e.g. Forth), are simpler.

I think this makes RPN calculators so popular now. And yes, RPN firmware for HP-50g (a-la WP-34s) could be very popular.

Everything here reflects my very subjective point of view.


#20

I started programming RPL with the HP28S and never really had a problem with RPL based machines. I program for a living, primarily in C derivative languages (I programmed C itself for a decade) as well as Pascal derivatives such as Delphi and this may be partially why I have never seen RPL as particularly hard to learn.

Many of the large function set you refer to were, I suspect, added for performance reasons. Take for example your own examples of DUP2 and DROP2. One could easily do DUP DUP or DROP DROP however, either of these would require additional parameter checking as performed by each User RPL command. Having DUP2 and DROP2 available eliminates half the parameter checking of using DUP DUP or DROP DROP it also eliminates a call/return and in the case of DROP DROP, where it might very well be implemented as a stack pointer adjustment, it could eliminate half the code. This may not matter so much in the current HP50g and would matter even less if the command set were implemented natively instead of via an emulator, however, it did make a difference for the considerably slower HP48SX. Once implemented HP saw fit (and IMHO this was a good decision) to maintain the same functionality in newer machines. If you think of RPL in terms of processor architecture it would very definitely be considered a CISC machine. Throw in everything including the kitchen sink, cabinets, and any other odds and ends you can think of. While this might make it hard to remember the entire command set and it certainly makes it possible to do things multiple ways it also offers power and lots of opportunities for performance tweaking.

While RPN is definitely simpler for "quick and dirty" solutions it has neither the power nor the maintainability of a well written RPL program which, due to enforced structure and named variables and subroutines can be self-documenting if the programmer makes just a little effort. Give me both in the same machine (without use of an additional emulator layer) and I would be delighted. Even better would be to provide a built-in C compiler or interpreter as would be possible with the newer processor architecture alongside the existing tools (and an RPN layer) and in my opinion the machine would be darn near perfect from a programmability point of view. Of course one can use a cross compiler but I like the ability of being able to develop code wherever and whenever I so choose.

This, of course, is just my 2 cents worth after using RPL based machines since the 28S. Note that I have also used RPN since the 41C and before that with borrowed HP67's so my experience includes both paradigms.

Cheers,

-Marwan


#21

I agree with you, it is not because a command is available that you have to use it. I have often found myself writing some complicated code only to find that one command does it for me. I would consider that as an advantage rather than a nuisance.

As for the argument that you can't do keystroke programming in RPL, I don't follow it. You just start with << do your keystroke sequence and end with >> I can't see anything complicated there...


#22

And I agree with you--we can start a mutual agreement society here <g>. Keystroke programming IS available on the HP48 and above. What I think some users are bothered by are the control structures. It is much easier for non-programmers and even some programmers, even if less neat, to use simple tests and a goto rather than the more powerful and more complex control structures offered by the RPL machines. At least that is the only conclusion that I can come to when I hear the complaint that the HP48 machines are not keystroke programmable.

I still think that for quick and dirty programs with a couple of very simple loops providing an RPN emulation mode would not hurt sales one bit.

Cheers,

-Marwan

#23

Agree with everything you say here.

>Even better would be to provide a built-in C compiler or interpreter...

If you're actually looking for something like this, try ND0 on your nearest iOS device. Programmable in RPL (and RPL+) and JavaScript (a C-like language).

>Give me both in the same machine (without use of an additional emulator layer) and I would be delighted.

See my other post.

#24

I worked with and programmed RPN calculators (1977:HP-25, 1986:HP-11C) for eleven years before buying an HP-28C in 1988. I remember that learning PRL was a major paradigm shift for me and it took a fair amount of effort to become proficient at it. I do admire its purity (I did not mean that line to sound creepy like it did in the movie "Alien"!). On RPN machines some operations such as STO, FIX, ENG, SCI, etc were post-fix operations requiring numeric data to be entered after the command key was pressed. RPL is strictly post-fix. When you execute a command in PRL you had better already have whatever data that operation requires on the stack.


Structured programming was a major change as well. Luckily, most programs I wrote were simple formula conversions so RPL was very much like RPN for those types of problems.


As I moved on to the HP-28S and finally to the HP-48SX as my daily engineering calculator, I found myself almost never using my HP-11C. I finally sold it around 2000 for about twice what I paid for it with the original set of batteries still going strong! Although I did not really use it anymore, I really miss that calculator and hope to pick up a HP-15C LE if I can convince my wife that I need yet another calculator :)

P.S. I am really looking forward to attending HHC this year! I have been wanting to go for years but either it was too far away or something else always came up. I can hardly wait to be there!!!

#25

Quote:
Take for example your own examples of DUP2 and DROP2. One could easily do DUP DUP or DROP DROP ...

That's not exactly what DUP2 does:

Duplicates objects in level 1 and level 2.

So it's more like OVER OVER.

Kind regards

Thomas


#26

True. Sorry. I was thinking of DUPDUP.

However, it does not change the point I was trying to make which is that DUP2 is faster than separate calls such as OVER OVER and DUPDUP is faster than DUP DUP.

Cheers,

-Marwan

#27

Perl is also cursed for its inelegance. A major philosophy of the language is "There's more than one way to do it," (TMTWWTDI). Not only are there multiple ways to do things, but there are zillions of things one can do with Perl. Programmers can write Perl in highly idiosyncratic ways, and often do. Reading someone else's code can be difficult sometimes. Much Perl code is criticized for looking like "line noise" (That's partly due to extensive reliance on regular expressions, without using the facilities the language provides for making them more readable.) But Perl is an extremely powerful language that adapts to the way you think. People with orderly thought processes tend to favor languages like Python, which successfully tries to fill the niches Perl occupies, but does so with elegant, though rigid object oriented syntax. On the other hand, if your mind is chaotic and messy like mine, you might feel more comfortable with Perl. (Actually, I impose order and structure in my Perl, as an exercise in taming my mental chaos to a degree. That underlines the fact that you don't have to write cryptic unmaintainable code with Perl, even if you can.)

RPL is a lot like Perl in that way. TMTWWTDI certainly applies to the 50g and others. Like Perl, RPL has a steep learning curve. (My opinion is that Perl is easier to get started with however.) I hated RPL until I broke through with understanding it. That took a long time, but once I got over that barrier, I found that I loved RPL for the freedom it offers to be insanely twisted and clever above and beyond my capability in those things. No doubt there are other reasons to admire RPL, but since I don't have many real problems I need to solve with my calculators, "geek fun" is all I need to enjoy the language.


#28

Maybe that is why I like RPL <g>. I think PERL is a great scripting language although I, like you, tend to try to impose order.

Cheers,

-Marwan

#29

Quote:
"There's more than one way to do it," (TMTWWTDI)

The acronym looks like phonetic writing to me. The WW should be OW in my eyes. ;-)

Back to topic: Many programming languages allow convoluted code. Unstructured spaghetti code in BASIC is one extreme, tightly optimized RPL stack manipulation code without any named variables the other. I have a coding style which makes my programs look similar independent of language, within the bounds set by the syntax.


#30

Good catch. But there's more than won way to spell it! :)

#31

Nothing wrong with Pascal, easy, clear and simple. People complained about C being too low level, but RPL code ive seen looks truly weird. I will reserve judgement, my 48g+ Arrives in a week and I will have a good crack at it.

Daniel

Quote:
my 2 (euro)cents

The major problem of RPL, IMHO, is lack of orthogonality and presence of many functions, which are not needed. Many high level languages, especially designed by Niklaus Wirth, have very concise and elegant syntax, while RPL has very cumbersome and complicated one.

Compared to RPL, RPN could be assumed to be assembler-like, but good assembler/instruction set (like DEC's PDP-11) is much more easier to program than overloaded, unsymmetrical, non-orthogonal high-level language. When high-level control structures are combined with giant set of assembler-level primitives, we get DUP2, DROP2 and other weird beauties. It seems as if RPL designers put everything of a kind in the box, trying to adhere to the latest programming technology trends.

Personally, I think RPL is very awkward and unelegant language. Learning curve is so steep not because RPL is powerful, but because it is ill-designed. However, it IS the most powerful calculator language available now, so there is no choice yet.

Maybe, there is a fundamental problem of designing programming language with stack structure. Stack languages are rather rare, but some of them (e.g. Forth), are simpler.

I think this makes RPN calculators so popular now. And yes, RPN firmware for HP-50g (a-la WP-34s) could be very popular.

Everything here reflects my very subjective point of view.



#32

Quote:
Nothing wrong with Pascal, easy, clear and simple.

Not the phoney first year assignments I submitted to select tutors back when I was doing postgraduate study :-)

It is possible to write totally awful programs in any language. Some languages make it easier of course...


- Pauli

#33

First of all I don't necessarily agree with everything you quoted. But the main issue is you would *completely* give up any semblance of keystroke programming. Comments posted on this site not withstanding, RPL *is* keystroke programmable. Not in the way that RPN was, but taking out the added complexity of control statements you can key in a simple program to reproduce a series of keystrokes (my ultimate definition of keystroke programming) with a few seconds effort. If you want a *real* programming language in addition to RPL (and/or RPN) that's fine and I would be all for it but don't remove the ability to write quick and dirty programs. And make the language 'C', not Pascal.

Just MHO.

Cheers,

-Marwan


#34

Excellent point.

In my mind, RPL is about the simplest way to add a handful of common control structures to an otherwise RPN model of operation.

The "steep" learning curve isn't really in the language (which is minimal; and the only odd thing I can think of is the clumsiness of having to bind local vars to "defining procedures"), but the command set. And here, you choose/use what you need. It's good that the kitchen sink is thrown in, as it gives you a nice set of commands/math abilities you would otherwise have to implement yourself (depending on your needs).

The "power" of RPL comes from the fact that it knows about objects, and has polymorphism (in the OO language sense). "+" works with Reals, Complex numbers, Vectors, Matrices, etc.
That aspect is cool and respectable, even in 2011.

(And since RPL machines support more objects/types, that makes them arguably superior to earlier RPN machines--if you need those types and/or functions, that is.)

I think, being stack-oriented is a strength and weakness, and a detail not to be ignored when comparing RPL (or RPN) to other languages. It sometimes makes for terse code for simpler jobs, but it makes reading RPL quite hard. You have to actually parse the code to "get" what is being accomplished (and what constitutes the 'lvalue' in an assignment).

I don't think RPL is very suitable for longer programs. But for small jobs, it's quite sweet. Starting with the fact that you only need one char to start a program and no syntax for inputs and outputs (as they come from, and go to, the stack).

#35

I love Pascal _and_ RPL :)

For Pascal on 48/49/50 have a look at :

HP Pascal Studio

here an exemple of program :

Mur de brique Pascal v0.1

And the code (newer version which correct some problem you can see on the video) :

Program CasseBriques;
{ v0.2 12/2/11 }

Uses SystemHP,CrtHPmini_49,GraphHP,GameHP,MathsHP_49;

Static Mvt : Array[1..8, 1..3, 1..2] Of Integer =

1, 0, 1,-1, 1,-1 {Direction 1 -3---2- }
, 0,-1, 1,-1, 1,-1 {Direction 2 4-----1 }
, 0,-1,-1,-1,-1,-1 {Direction 3 ------- }
,-1, 0,-1,-1,-1,-1 {Direction 4 ---O--- }
,-1, 0,-1, 1,-1, 1 {Direction 5 ------- }
, 0, 1,-1, 1,-1, 1 {Direction 6 5-----8 }
, 0, 1, 1, 1, 1, 1 {Direction 7 -6---7- }
, 1, 1, 1, 0, 1, 1;{Direction 8 }

Var i,j,Rx, Bx, By, Bx2, By2,
Dir, Choc, b, Vies,
Vitesse,Niveau, NBrique : Byte;
TapeMur, Perdu, GagneNiveau: Boolean;
Score,k: Integer;
c: Char;

Procedure DessineMur;
Begin
ClrScr;
Box(0,0,100,80); Bar(2,11,98,30);
For i:=1 To 5 Do ClearLineH(2,98,10+i*4);
For i:=1 To 14 Do ClearLineV(1+i*7,10,30);
Bar(Rx,78,Rx+11,79);
GotoXY(27,1); Write('Score');GotoXY(27,2);Write(Score);
GotoXY(27,7);Write('Niveau'); GotoXY(27,8);Write(Niveau);
Perdu:=False; GagneNiveau:=False;
Vitesse:=23-Niveau*3; NBrique:=0;
End;

Procedure BougeRaquette;
Var D : Char;
Begin
D:=' ';
For j:=1 To Vitesse Do Begin
If RightPressed Then D:='R';
If LeftPressed Then D:='L';
End;

Case D Of
'R': If Rx<88 Then
Begin
ClearLineV(Rx,78,79);
LineV(Rx+12,78,79);
Rx:=Rx+1;
End;
'L': If Rx>1 Then
Begin
ClearLineV(Rx+11,78,79);
LineV(Rx-1,78,79);
Rx:=Rx-1;
End;
End;
End;

Procedure BougeBalle;
Var Mx,My : Integer;

Begin
i:=1;

Repeat
Bar(Bx,By,Bx+1,By+1);
BougeRaquette;
Bx2:=Bx+Mvt[Dir,i,1];
By2:=By+Mvt[Dir,i,2];
If Bx2>=99 Then Begin
Case Dir Of
1: Dir:=4;
2: Dir:=3;
7: Dir:=6;
8: Dir:=5;
End;
Bx2:=98;
Exit;
End;

If Bx2<=0 Then Begin
Case Dir Of
3: Dir:=2;
4: Dir:=1;
5: Dir:=8;
6: Dir:=7;
End;
Bx2:=2;
Exit;
End;

If By2<=0 Then Begin
Case Dir Of
1: Dir:=8;
2: Dir:=7;
3: Dir:=6;
4: Dir:=5;
End;
By2:=4;
Exit;
End;

BougeRaquette;

If By2=77 Then Begin
k:=Bx-Rx;
If Dir In [5,6] And (k in [12..14] Or (k=15 And RightPressed)) Then k:=11
Else
If Dir in [7,8] And ((k>-4 and k<0) Or (k=-4 And LeftPressed)) Then k:=0;

If k in [0..11] Then
Case k Of
0,1 : Dir:=4;
2,3 : Case Dir Of 5,6: Dir:=4; 7,8: Dir:=3; End;
4..7 : Dir:=9-Dir;
8,9 : Case Dir Of 5,6: Dir:=1; 7,8: Dir:=2; End;
10,11: Dir:=1;
End
Else
Begin Perdu:=True; ClearBar(Bx,By,Bx+1,By+1); End;

Exit;
End;

If By2<32 Then Begin
Choc:=0; TapeMur:=False;
ClearBar(Bx,By,Bx+1,By+1);
If Point(Bx2,By2) Then Choc:=1;
If Point(Bx2+1,By2) Then Choc:=Choc+2;
If Point(Bx2+1,By2+1) Then Choc:=Choc+4;
If Point(Bx2,By2+1) Then Choc:=Choc+8;
Bar(Bx,By,Bx+1,By+1);

Case Dir Of
1,2: Case Choc Of
1,3: Begin TapeMur:=True; Dir:=9-Dir; End;
2 : Begin TapeMur:=True; Dir:=Dir+4; End;
6,4: Begin TapeMur:=True; Dir:=Dir+2; End;
End;

3,4: Case Choc Of
2,3: Begin TapeMur:=True; Dir:=Dir+2; End;
1 : Begin TapeMur:=True; Dir:=Dir+4; End;
9,8: Begin TapeMur:=True; Dir:=5-Dir; End;
End;

5,6: Case Choc Of
4,12: Begin TapeMur:=True; Dir:=9-Dir; End;
8 : Begin TapeMur:=True; Dir:=Dir-4; End;
1,9 : Begin TapeMur:=True; Dir:=Dir+2; End;
End;

7,8: Case Choc Of
8,12: Begin TapeMur:=True; Dir:=9-Dir; End;
4 : Begin TapeMur:=True; Dir:=Dir-4; End;
2,6 : Begin TapeMur:=True; Dir:=Dir-2; End;
End;
End;

If TapeMur Then Begin
NBrique:=NBrique+1;
Mx:=((Bx2-1) Div 7)*7 + 1;
My:=((By2-10)Div 4)*4 + 10;
ClearBar(Mx,My,Mx+7,My+4);
Score:=Score+5; GotoXY(27,2); Write(Score);i:=3;
End;
End;
i:=i+1;
If By2<77 Then Begin
ClearBar(Bx,By,Bx+1,By+1);
Bar(Bx2,By2,Bx2+1,By2+1);
End;
Bx:=Bx2; By:=By2;
Until i=4;
End;

Begin
ClrScr;
Box(15,20,115,60);
Box(16,19,114,59);
GotoXY(8,3); Write(' CASSE-BRIQUES ');
GotoXY(8,4); Write(' (c) Nemo 2011');
GotoXY(8,6); Write(' ENTER pour Jouer');
GotoXY(8,7);Write(' <- Deplace ->');
GotoXY(8,8);Write(' Exit : DEL');
Repeat Until KeyPressed; c:=ReadKey;

Score:=0; Vies:=10; Niveau:=1;Rx:=35;

Repeat
{Nouveau Niveau}
DessineMur;

Repeat
{Nouvelle balle}
By:=75; Bx:=Rx+5; Dir:=Random(3)+1;
GotoXY(27,4); Write('Vies');
GotoXY(27,5); Write(Vies-1);
Repeat Until EnterPressed; C:=ReadKey;
Perdu:=False;
DisableInterrupt;

Repeat
BougeBalle;
If NBrique=70 Then GagneNiveau:=True;
Until GagneNiveau Or Perdu Or ExitPressed;

EnableInterrupt;
ClearBar(Bx,By,Bx+1,By+1);
If Perdu Then Vies:=Vies-1;
Until Vies=0 Or GagneNiveau Or ExitPressed;

Niveau:=Niveau+1;
Until Vies=0 Or ExitPressed;

Repeat Until EnterPressed Or ExitPressed;

Edited: 11 Sept 2011, 2:56 p.m.


#36

Gilles, the site is in French only. Is there any free version of Pascal Studio (if so, how could it be obtained)? Does it work with HP-50G?


#37

Yes It works on HP50G. It also works with Emu48

Note that it's not a perfect tool and there is some bugs. It's a subset of Pascal langage ( no records and type for example, and of course no Objects).

The project seems dead few years ago.

It's open source so i think you can find some download area. All the docs are in french.

What is interesting is :

- The graphics commands are very fast !
- Fine keyboard management
- HP48/49/50 compatibility
- Easy Saturn integration (ASM command like in Turbo Pascal)
ex: http://hppascal.free.fr/pages/library_show.php3?file=graphhp.unt
- Bin not too big for simple program

The minus :
- some bugs
- a subset of Pascal
- The project is dead
- It seems not possible to exchange parameters with RPL stack (the documentation is very unclear on this point)
- You need a PC to generate the binary

Imo, it's more a proof of concept that an ultimate tool, but it's usable (for exemple the PAC MAN or TERTRIS exemples are very impressive - and it works on 50g with a new compilation and some change to slow down the programs ). You would not use it for a 'serious' project but you can have fun with. Note there is also sprites and bitmap management

If there is some interest note that I have partialy adapted the Math UNIT to work on HP49G+/50


#38

I could not find any way to download it. Payment does not work, and there are no sources/binaries I can find. It's a pity.


#39

The website and documentation says HP-Pascal is a freeware and opensource. I sent you an email. The zip installation file is only 1 MB

Just to compare speed of RPL and HP Pascal, a solution for the problem 1 of Euler project
http://projecteuler.net/index.php?section=problems&id=1

HP PASCAL :

Uses CrtHP_49;
Var i,t : Integer;
Begin
For i:=1 to 999 Do
If i mod 3=0 Or i mod 5=0 Then t:=t+i;
Write(t); Repeat Until Keypressed;
End.

s : 0.5057 sec
Code size : 406 Bytes

User RPL

«
0.
1. 999. FOR i
i 3. MOD i 5. MOD AND NOT { i + } IFT
NEXT
»

s: 13.29 sec
Code Size : 73,5 Bytes

Pascal is 26 times faster


Edited: 12 Sept 2011, 2:54 p.m.


#40

Mon Dieu!

Très vite!

Edited: 12 Sept 2011, 9:01 p.m.

#41

Well, all HP Pascal files are available here: http://hppascal.free.fr/resources/

#42

File this one under "careful of what you ask for!" :)

#43

I see no reason to use RPN on the 48 but if one have to, there are 41 emulators. To use RPN on RPL machine is like breaking walnuts with a microscope. ;)

#44

(and this echoes others sentiments).

I've been using RPN since the days of the 35/45/65 (~40 years), use a 42s/35s/15c/48 regularily and have found that this highly discussed 'transition' to RPL to be highly over-rated. It is really very similar and I find that it requires very little attention that the machine is not RPN.

TomC

#45

Quote:
Can the 48's RPL be ignored and programmed RPN?

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=802
Quote:
If thats the case, why would you use a 42s?

  1. RPN Native.
  2. Pocketability.
  3. Just short of a zillion years of battery life.
There is no such thing as a universal solution that works for all people in all cases.


Edited: 7 Sept 2011, 10:13 a.m.


#46

I love Hrast's emulators. He has them for many of my favorite machines. In addition to HP-41X, there are HP-42X, HP-71X, and HP-1xE for the Voyagers, except the 10C. Until Cristoph Giesselink came out with EMU71 for Windows, HP-71X was the only emulator that could run my YATZ71 game. (It is still the only one that can run it with sound. :) They are well worth a look.


#47

HrastProgrammer: Sainthood immediately!

;)


#48

Hahahahaha :-)

#49

Quote:
Looking back at the HP 48G, it seems to have more functions on the keyboard, and a lovely design.

More functions on the keyboard, compared to what? The total functionality of the HP 48G is a much dimished subset of the later HP 49g+ and HP 50g. But the functions explicitly shown on the keyboard of each of these is very similar. There are menus after menus after menus on all of these machines due to the tremendous number of functions they support.

I purchased an HP 48SX in 1991, and a HP 48GX in 1996. They have great keyboards, but typically some of the fuzziest low-contrast LCDs that anyone ever put on a calculator. Only very late in HP 48GX history did decent sharp high-contrast LCDs show up. They are painfully slow, and have no way of receiving AC power during long program execution times.

Essentially all the capability of the HP 48GX is contained in the HP 49g+, plus CAS, USB, much greater speed, LCD quality, and memory capacity (with SD cards). (Unfortunately, the keyboard of most HP 49g+ units suck.) Also very importantly, 49g+/50g firmware can easily be upgraded by downloading the image on a PC to an SD card, then upgrading from that SD card in the calculator. The HP 48S and G series have no firmware upgrade capability. IIRC, the last HP firmware in the 48S and 48G series is Version R, but if you have something earlier on your machine then you're stuck with it forever. The 49g+/50g also have an extensive developer's application built in that allows access to the internals at either the ARM or the emulated-Saturn levels.

The 2006 HP 50g corrected the 49g+ keyboard problems, improved the appearance, and added the capability for operation from external power through the USB port. If one can stand the large size and attendant weight, and if one is willing to learn User RPL, the HP 50g is the finest hand-held calculator made by anyone anywhere anytime. Not perfect, just all things considered the best that happens to be in existence since 2006...and a giant advance over the HP 48G series by any measure. (I haven't used my 48SX and two 48GX units at all since getting my 49g+ and 50g.)

Quote:
Im not ready to evaluate RPL vs RPN...why would you use a 42s?

You are not ready to ask that question if you have not personally evaluated RPL vs. RPN.

Edited: 7 Sept 2011, 7:55 p.m.

#50

If you'd like to play with RPL a little, you can use one of the excellent PC-based development environments.

For User RPL, I like HPUserEdit 5. Note that the program defaults to Spanish, but you can change it to one of several others (including English) as described here

The Advanced Users Reference contains a detailed tutorial on RPL programming at the beginning, as well as descriptions of all the commands. I believe the link given has the version with bookmarks to make it easy to navigate.

There are several mini-challenges on hpcalc.org that make nice programs to attempt.

Good luck!
Dave


#51

I agree... HPUserEdit is a great tool with a perfect integration with emu48. Well done INFORM INPUT and CHOOSE wizard are present and much more

There is also a french version
A screen shot :



http://imagik.fr/uploads/412269

I uses this to solve Euler project problem and i'm near 100 solved problems (it's my objective, still 7 ) , most of them in RPL
I learned UserRPL with this book : "La Maitrise De La Hp-48 - Tome 1 - Programmation Et Exercices Jean-Michel Ferrard" wich is very interesting. I think you need a book or on-line documentation because HP doc are very very poor about User RPL programming.(not the description of each command in the AUR but how to combine all this;) )

Edited: 7 Sept 2011, 4:59 p.m.

#52

Ill do this over the Christmas break!

Daniel


#53

Besides using HPUser edit, try coding on the 49g+ itself. The large screen (and the optional choice of the size 6 font) makes writing and editing code quite comfortable. I hardly ever plot anything on my 50g, but I find the large LCD is great for editing multi-lined RPL code (anywhere you happen to be - bus, train, plane, automobile).

After several hours of coding on the device you'll get good and look Elton John in "Tommy". People will wonder what the @#$% you are doing..

Edited: 7 Sept 2011, 11:04 p.m.

#54

If someone is interested in implementing a RPN interpreter within an existing framework for calculators running on modern mobile devices (iOS/Android), please contact me.

I could provide skeleton code for a class that would permit an RPN model of programming (and possibly calc operation) alongside and within an existing RPL model of programming (and calc operation).

To be written in JavaScript, with an existing framework of math functions, I swear this cannot be done much more easily/comfortably.


#55

A single plug for your iOS product gets a pass by me. But, since this is the second mention of your ND0/ND1 app in this thread, this should perhaps be moved to the "Classifieds" section of the MoHPC.


#56

Sorry if this post offended you. I explicitly didn't name the product, trying to minimize any "plug" suspicions.

The post is simply an invite for cooperation.

Is the Classifieds section the right place to suggest collaborations?
What would be the harm, if a project were started as a result of this discussion?


#57

We know that development discussions are *cough* strictly off limits here. :)

(Since irony is infamous for not surviving cultural translation, please note the "smiley" above. :)

#58

My apologies Oliver. I assumed that ND1 was just another iOS calculator app being added on the growing dung heap that is the Apple App Store (tm).

After taking a look, I like what I see and have actually purchased a copy.


#59

No problem, Mark. Thank you, and I hope you'll enjoy the calc.

If now you sign up for the RPN module, you'll make my day. ;-)

#60

That is obviously not a commercial pitch in the sense that he is not asking you to buy anything.


Possibly Related Threads...
Thread Author Replies Views Last Post
  [PRIME] RPN: another attempt at returning more than one value to the RPN stack Marcus von Cube, Germany 5 382 11-05-2013, 02:44 AM
Last Post: Marcus von Cube, Germany
  HHC 2013 RPN Programming Challenge - Final Thought Jeff O. 7 378 10-17-2013, 11:02 AM
Last Post: Jeff O.
  HHC / HP Museum Programming Contest for RPN and RPL machines Gene Wright 18 774 09-22-2013, 09:39 AM
Last Post: Miguel Toro
  HHC 2012 RPN Programming Contest - 10-Step Way-After-Nashville Solution Jeff O. 32 1,250 10-12-2012, 01:41 AM
Last Post: Paul Dale
  HHC 2012 RPN Programming Challenge Conundrum Jeff O. 15 537 10-08-2012, 03:34 PM
Last Post: Gerson W. Barbosa
  HHC 2012 RPN Programming Contest Gene Wright 73 1,427 09-28-2012, 12:43 PM
Last Post: x34
  HHC 2012 programming contests coming soon (RPN and RPL) Gene Wright 9 442 09-21-2012, 03:38 PM
Last Post: Paul Dale
  RPN Simuator for 28/48 Matt Agajanian 8 272 06-01-2012, 07:28 PM
Last Post: Les Wright
  Help with RPN programming hpnut 36 1,160 03-03-2012, 09:31 AM
Last Post: Bill (Smithville, NJ)
  Re: RPN Programming exercise (HP-42S) Gerson W. Barbosa 1 142 02-27-2012, 05:51 PM
Last Post: Marcus von Cube, Germany

Forum Jump: