New RPL firmware for 50G - Revisited

[Claudio L.]

Hello,
Just wanted to inform the community that this project has effectively started. Very soon we'll have a mailing list and a website you can join to track our progress and help shape the new language.
In the month and a half or so since I posted the original thread, a lot has happened behind the scenes.
We've been having very interesting discussions and we have now a prototype implementation of the new RPL engine, still incomplete but moving at a good pace.
Just as a teaser, the new compiler allows declaring local variables anywhere you want (as opposed to being limited to the -> a b c << >> syntax, which is also supported for compatibility reasons), and after declaration any references to the variable will be automatically optimized into internal GETLAM/PUTLAM commands, making local variables almost as fast as using the stack.

So far we have:
* Integer type with basic arithmetics (64-bit integers).
* Strings
* Local variables
* Overloadable basic operators
* Loops (FOR/NEXT/STEP, START/NEXT/STEP, etc)
* An extensible compiler that doesn't need to change when you add commands or even new object types.
* A basic runtime environment capable of executing all of the above.

This is just a humble beginning, so stay tuned because there's a lot more to do. I'll inform in this forum when the mailing list and website are up and running.

Claudio (and the newRPL team!)

[Tugdual]

How do you guys start such a project? I mean for a starting point, what understanding of the official firmware do you have? Are you reverse engineering the existing one?
Say I want to start my own custom firmware for the Prime, what shall be the effort?

[David Hayden]

(02-19-2014 04:01 PM)Tugdual Wrote:  How do you guys start such a project?

I think the motivation came separately from Claudio and myself. Claudio was wondering what it would take to reimplement the 50g ROMs in native ARM code. Independently, I had started a project to implement system RPL in C++ code. Claudio posted something here and pretty soon Han joined in too.

To me, the first big question was "what level of compatibility?" We decided on userRPL at the source code level. In other words, if you type in a userRPL program, we hope that it will run in newRPL. On the other hand, a userRPL program in binary form won't run (although it may be possible to convert it automatically). SystemRPL programs definitely won't work. Saturn assembly is out and most ARM assembly will need to change since we aren't following the binary interface.

The up side of limited compatibility is that we can take advantage of modern hardware. The MMU will make memory management easier. Objects are all 32-bit aligned to increase access speed. I think the coolest thing is that Claudio came up with a framework to allow adding user-defined types in a meaningful way.

Han and Claudio, please correct anything that I have misstated.

Dave

[Han]

(02-19-2014 04:01 PM)Tugdual Wrote:  I mean for a starting point, what understanding of the official firmware do you have? Are you reverse engineering the existing one?

I can only speak for myself. I had actually started writing my own replacement ROM for the HP48 series, but that project has been put on hold indefinitely. I am fairly familiar with the ROM code for the HP48 series, as well as the HP42 series. I am also quite familiar with the hardware of the HP48 series. When I was working on a replacement ROM, I did actually disassemble the entire ROM contents, mainly to get a better understanding of the hardware interface. I got sidetracked when I finally decided to get the HP50G (very late, about 5~6 years after it was released!). I devoted a lot of my time toward updating Jazz so that it would work for the HP50G series. Recently, the Prime has taken up a lot of my free time :-)

Quote:Say I want to start my own custom firmware for the Prime, what shall be the effort?

That all depends on what you want the new firmware to do. If you don't care about backward compatibility, and want a custom firmware, then the only thing you really need to know is how the hardware works, and where certain hardware addresses are mapped. Once you have that, you can make your firmware behave however you like. A lot of the information is available in specification sheets for the various components on the PCB. I don't think there are any exotic (custom) chips, so you may be able to find all the info you need from googling.

You would need a cross compiler for the ARM chip -- unless you decide to do your firmware in ARM assembly.

One of our goals for a new HP50G firmware is to do clean-room implementation of RPL. So we will not be relying on any existing ROM code. Instead, our specifications are based off of RPLMAN.DOC.

[Claudio L.]

(02-19-2014 04:01 PM)Tugdual Wrote:  How do you guys start such a project?
I mean for a starting point, what understanding of the official firmware do you have?

Funny you ask, because even though we do collectively have a fairly deep understanding of the internals, we choose NOT to follow them!
We want to "replace" the existing firmware, so why do we need to understand it?
We need to understand the hardware where we will be running, yes, but not the firmware. And we'll try to keep hardware dependency to a minimum, so the project can run on multiple architectures (waaaay out in the future).

(02-19-2014 04:01 PM)Tugdual Wrote:  Are you reverse engineering the existing one?

Not at all. No hp50g will be harmed during this project.
The last thing we want is a "cease and desist" letter from HP, so absolutely not copying anything, not even looking.
The new system will be designed to take advantage of a modern 32-bit architecture, while the original design was done to maximize the benefits of a 4-bit processor. As you can imagine, the best solution to the same problem will be completely different if you have such different architectures.

Claudio