Which machine to program

[CheshireChris]

I’m in a bit of a quandary at the moment.

I’m a retired former professional physicist, astronomer, and software developer at various times during a 40-year career. To keep my mind active, and simply because it’ll be great fun, I’d like to have a go at writing some astronomy software for HP calculators. The machines I have available to me are:
- HP-41CV (and its SM clone, the DM41X)
- HP-42S SM clone
- HP-48GX
- HP-50G
- HP Prime

My question is simply which device should I start writing software for? My head tells me the Prime, because of its almost limitless storage space (well, 256MB…), fast CPU, modern high-level languages in the form of HP-PPL and Python, and ease of PC development in the form of the HP Connectivity Kit. On the other hand I’m rather enamoured with the RPL of the 48GX and 50G.

Does anyone have any thoughts on which would be the better programming environment, both for me as a developer and in terms of the size of the potential audience? I’m not interested in commercial software development (done that and got the t-shirt), but it would be nice if there were a reasonable number of other people who might have an interest in my output.

All thoughts would be very welcome.

[Maximilian Hohmann]

Hello,

I am only an amateur astronomer but I would use nothing else but the Prime for astronomy software. You can connect it to a PC and download all the ephemeris data and it has enough memory for large datasets.

Regards
Max

[gehakte_bits]

I concur: if you come from an agile/devops environment and write any more than 10 lines of code, the commenting/documentation feature and quick edit/emulation of the Prime (SDK/emulator) is invaluable. And if you run the emulator, you have ample/infinite local storage (AFilesB).

If you choose to export to a real Prime, some PPL native developed flexelint /codemaid equivalent can easily strip off the comments/space-formats to shrink your source files if needed.

RPN/RPL is still fun for small algos, but you will be spoiled by the development environment and the speed of a Prime.
The Prime does not have a ’familiar’ file system, so I recommend creating single xxx_lib file(s) for common clustered feature functions (i.e. a nav_lib for your common astro/celestial conversions).

Enjoy!

[carey]

While the Prime is the most sensible choice for all the reasons stated, I'm going to make a case for the 48GX/50g :)

1) Storage, PC connectivity, and speed issues that favor the Prime are partially offset for the 48GX/50g when using an emulator (e.g., a smartphone app).
2) Since demand for calculator software is so low, it seems to me that you should write the software principally for your own enjoyment using tools you enjoy using. I'm sure you will find some people who appreciate and use your software no matter which calculator platform you choose. While the worldwide user base for the Prime must be far greater than for the 48GX/50g, I don't know how much its educational use numbers translate into interest in astronomy software, especially at the sophisticated level that it sounds like you are capable of writing it.
3) Like yourself, I too am enamoured by RPL. One reason it would be cool to write advanced astronomy software in RPL is that William C. Wickes (HP project manager for the 28C/S and 48SX and deeply involved in the development of RPL) did his physics Ph.D. work in astronomy at Princeton with physics Professor Robert Dicke (who first predicted the 3 degree K microwave background radiation but somehow didn't receive a Nobel prize). I can't help but think that somewhere in mind in the development of RPL was its utility for writing scientific software.
4) AI tools make it relatively easy to translate programs written in one language (e.g., RPL) into another (e.g., PPL) or vice versa -- again an argument for writing source code in the language you prefer.

Having said all this, the Prime remains the sensible choice. :)

[AnnoyedOne]

(09-22-2024 06:00 PM)gehakte_bits Wrote:  The Prime does not have a ’familiar’ file system...

I don't understand the desire to use custom stuff these days.

Over a decade ago I developed a product that used generic SD cards (FAT/FAT32) for data storage. Cheap, readily available etc. Even back then almost everyone had, or had access to, a SD card reader. Create files on a PC or whatever and copy them over. The same the other way.

USB is similar. Why develop a custom connector when mini/micro ones are standard and easier/cheaper? If one sells a custom cable ok, but if not why bother?

Sorry for the rant but I see no point re-inventing the wheel.

A1

PS: Many years ago I won an Apple 2GB Nano MP3 player at some event. I already had a MP3 player that had a standard mini-USB connector and accepted standard microSD(HC) cards.

I decided to try the Nano anyway. It used a custom USB cable but used the standard mass-storage mode for transferring music files. It would play the ones I transferred but there was some issue doing so that I've long since forgotten. Using Apples's iTune software solved that but I saw that totally custom format files/folders were used on the device. The Nano sat in a drawer after that until I gave it away. No thanks.

I still have that MP3 player and it still works. Plus transfer any standard format files (music/playlist) to it and it sees them. The same with the microSD(HC) card. And it cost a lot less than an Apple Nano.

PPS: I purchased a well known brand tablet about 12 years ago to learn about Android etc.

It too uses a custom connector for power/USB but I have the cables. That said it also has a standard microSD(HC) card slot. The PC application for transfer/backup for it was also custom (and slow).

Some years ago Google Play stopped working on it. These days I find/download standard .apk files and put them on a card to add/update apps. The same with other files.

No doubt the manufacturer wants me to buy a new model. Being a "cheap bastard" I refuse to.

[Mark Power]

I've programmed all of the machines you have suggested and my thoughts are:

1) HP-41 is a fantastic machine, but its limitations could well frustrate you in terms of speed, limited display, little available memory, lack development tools if you use a Mac (I love David Assembler though - for old school mcode on the calculator). From a developer point of view, RPN and mcode programs can easily turn into 'write once, read never' unless you are scrupulous in commenting your source code off the calculator. On the other hand, it is the best HP calculator ever.*

(*as voted for at HHC 2023)

2) I also have a soft spot for RPL on the 48/49/50. Lots of memory, library support, graphics, perhaps more tricky to develop code for than both the 41 and the Prime. Also there are many RPL astronomy programs already available at hpcalc.org:

https://www.hpcalc.org/hp48/science/astronomy/
https://www.hpcalc.org/hp49/science/astronomy/

3) The Prime has great hardware including a backlit display, which might be useful at night. The connectivity kit is ok for development, but could be better - particularly on Mac. Apps are easy to write, it is just a shame that PPL doesn't support libraries nicely - though you can use dot notation to access functions in other Apps/programs.

Once you have got used to the Prime's foibles you can write a lot of high level code quickly - I wrote a couple of thousand lines of code for monitoring the Solar Eclipse in Texas earlier this year.

You could delve into Python and maybe reuse some existing code from other places if that takes your fancy (more painful than PPL at the moment, in my opinion).

There are far fewer Astronomy Apps available for the Prime, so you would be expanding the catalogue of what is available:

https://www.hpcalc.org/prime/science/

Overall, if you want to write complete applications I'd be tempted to go with the Prime as others have suggested.

[dm319]

I'm going to suggest the HP42s/DM42.

It's a very popular platform. And the spaghetti code with multiple GOTOs will be a refreshing change for you.

[carey]

(09-22-2024 07:44 PM)Mark Power Wrote:  Once you have got used to the Prime's foibles you can write a lot of high level code quickly - I wrote a couple of thousand lines of code for monitoring the Solar Eclipse in Texas earlier this year.

Mark, I appreciated reading your helpful experience programming the various calculators so the following is just a question and not a criticism of the need for thousands of lines of code. I’m curious what portion of the solar eclipse program (e.g., gui & menus, plots, comments, I/O, control structures, or other) make up the bulk of the code and how you think the # of lines would compare if attempted in RPL? Thanks!

[avsebastian]

Hi. I think the most important thing here is
a) the scope/portability that the program you create would have; and
b) the experience you have in the programming language.

As annoyedOne says, the ideal option would be to program an app for Android - iOS - Windows. But maybe, you don't have enough expertise in the language on those platforms. In that case, you would have to program for calculators. For the physical calculator, it would be the Prime... but if you don't have it at hand? Wouldn't it be better to use your smartphone? Then it's a good idea to follow Carey's advice: use emulators. Hp Prime dont work on android/iphone. We only have RPN and RPL calculators left. My experience, the emulator for the HP 48/49 is much better than the RPN emulator on Android. It would be a good alternative.

[John Keith]

(09-22-2024 06:08 PM)carey Wrote:  One reason it would be cool to write advanced astronomy software in RPL is that William C. Wickes (HP project manager for the 28C/S and 48SX and deeply involved in the development of RPL) did his physics Ph.D. work in astronomy at Princeton with physics Professor Robert Dicke (who first predicted the 3 degree K microwave background radiation but somehow didn't receive a Nobel prize). I can't help but think that somewhere in mind in the development of RPL was its utility for writing scientific software.

This is likely considering that Forth, one of the languages on which RPL is based, was written by an astronomer for controlling telescopes. Wickes was also involved in the development of the HP-71B and its Forth-Assembler ROM.

[AnnoyedOne]

(09-22-2024 10:24 PM)dm319 Wrote:  And the spaghetti code with multiple GOTOs will be a refreshing change for you.

Programming rule #2.

NO goto's unless absolutely necessary. My calculators have "skip" logic.

And spaghetti is for eating not for coding with! REAL programmers don't eat quiche either

A1

[vaklaff]

(09-22-2024 04:09 PM)CheshireChris Wrote:  To keep my mind active, and simply because it’ll be great fun, I’d like to have a go at writing some astronomy software for HP calculators.
(…)
My question is simply which device should I start writing software for?

Don’t aim low, that won’t get you anywhere. Writing some app for the Prime will be keeping your mind active for how long, a week? Take the SwissMicros SDK instead and write an astro application not for but replacing the Free42 application you have in your DM42. Take advantage of full control over the display. Put zoomable sky maps there or whatever, I don’t use any astro SW but I’m sure the inspiration will come once you tame the platform. Will keep you busy for months, maybe years!

You are welcome! ;-)

[Mark Power]

(09-22-2024 11:03 PM)carey Wrote:  

(09-22-2024 07:44 PM)Mark Power Wrote:  Once you have got used to the Prime's foibles you can write a lot of high level code quickly - I wrote a couple of thousand lines of code for monitoring the Solar Eclipse in Texas earlier this year.

Mark, I appreciated reading your helpful experience programming the various calculators so the following is just a question and not a criticism of the need for thousands of lines of code. I’m curious what portion of the solar eclipse program (e.g., gui & menus, plots, comments, I/O, control structures, or other) make up the bulk of the code and how you think the # of lines would compare if attempted in RPL? Thanks!

On the Prime:

826 lines (including comments and blank lines) for the App, which coordinates calls to the following and also outputs a CSV file of results (largely reusing Mark Fleming’s RTable https://www.hpcalc.org/details/7715)

451 lines for USB HID controller and driving i2c devices

329 lines for Light sensor library (calls Hid and Plot4g)

580 lines for Temp, Humidity, Pressure and Gas sensor (calls Hid and Plot4g)

89 lines for Temp, Humidity, Pressure and Light sensors (calls above)

225 lines for Plot 4 Graphs (in real-time) (used by above)

I will get around to writing this lot up sooner or later, along with libraries to drive a DAC and read a 3D accelerometer (tilt sensor).

In RPL some things might be shorter, some longer. Implementing i2c, to read sensors, using serial on the 48/49/50 machines would be interesting (something I think Tony Duell may have done).

[carey]

Thank you Mark for taking the time to reply! As I’ve never written a program more than a few dozen lines it is informative seeing this breakdown and how much work goes into writing a long and useful program that accesses multiple sensors and devices and includes libraries and plotting. Thanks again!