HP-Prime File extension

[Paul D. Fox]

Hello everyone. Really enjoying the discussions on Prime. I got the HP48 when it was new, and wrote an emulator for it (the code is em48 - which I think people used in later emulators). Waited so long to get really excited again, sad that I am!

Got my Prime a few days ago, and gently getting used to it with the great conversations on here.

I am using Linux - havent looked at the CDROM yet, but can we up/download to Linux?

What is the normal file extension for Prime programs? (So I can add syntax coloring to my editor).

thanks

[debrouxl]

Hello,



AFAICT, there's no Linux (or more generally, third-party) tool for communicating with a HP Prime for the purposes of transferring files or upgrading the firmware.

We know, from the USB descriptors, that the Prime uses standard USB classes for both of those purposes: HID for file transfer, MSD for firmware upgrade. Therefore, it doesn't require users to install extra drivers, unlike, say, TI's calculators and cables, which use vendor-specific class.

However, the firmware upgrade protocol has not been fully reverse-engineered, and I'm not aware of any published work on reverse-engineering the file transfer protocol. USB protocols reverse-engineering work was recently eased by Wireshark gaining the ability to consume Windows usbpcap dumps :)



The normal file extension for Prime programs is .hpprgm. Prime programs are mostly UTF-16 little-endian texts, with a bit of extra metadata at the beginning.



These pieces of information are not (yet) found on wiki4hp. See http://tiplanet.org/hpwiki/index.php?title=HP_Prime and its sub-pages for more details.

[Paul D. Fox]

Great - thank you debrouxl. Thats very useful to know. (Shame they are UTF-16 and not UTF-8, but never mind!)

My Linux has problems seeing the HP - I presume the USB ID isnt in the known table, which is easy enough to fix, or will happen on the newer kernel/distro updates.

Interesting that we need to decode the USB protocol. I will ponder if its possible to leverage a Windows VM to monitor the traffic.

thanks

[debrouxl]

Yup, the USB ID wasn't in the table. I've just added it at https://usb-ids.gowdy.us/read/UD/03f0 , it should therefore appear in a future upgrade.



Unless HP officially documents it, we need to decode the USB protocol. That falls under the "reverse-engineering for interoperability purposes" category and is fortunately squarely legal in most countries :)

For this purpose, we can definitely leverage virtualized Windows. I occasionally did for minor changes to the third-party implementation of the TI Nspire protocol I'm currently the maintainer of. 99% of the work on the Nspire protocol was done years ago by the previous maintainer.



In 2013, Wireshark became a more friendly solution than e.g. SniffUSB commented text dumps, which the previous maintainer and I used for the Nspire.

[Tim Wessman]

Not really much to decode, but be aware it may still change with future updates (as will programming - some commands changed/added/removed/etc).

TW

[debrouxl]

That's understandable :)

As long as there's a way to identify the OS somehow (version number / feature level / date / whatever), it's possible to cope with changes.

[cyrille de Brébisson]

Hello

-> decode USB protocol

If you are trully interested in creating a linux con kit, contact me and I will help as much as I Can...

cyrille